BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / jdrbbs08.zip / DOCS_ETC.ZIP / DOCS_1.DOC < prev next >

Wrap

Text File | 1993-04-06 | 258KB | 4,590 lines

JDR_BBS .08 by John Rohner Well, you have taken the time to download JDR_BBS. Probably wondering: what have I gotten? First and foremost, it is a BBS program. A BBS program for the future. Completely original programming. Many new and unique ideas and methods. Unlimited expansion and growth potential. Incorporating much in itself that other programs rely on 3rd-party software to accomplish. I have tried, and will continue to try, to incorporate the best of all the BBS programs into this software. If you are the "artistic" type, or a programmer, this software is definitely for you. It has been designed to take maximum advantage of your creativity. The interface is FAST! Logging on and doing things are all optimized in the interface. Hot-key menu action on all things are the norm. There are not a hundred little "Would you like..." questions. Sure, all the commands are there--but unobtrusive, out of the way of those who do not want, or need, them. If it can make life easier on the sysop or user, it tries to do so. The software is balanced. Users and sysops have many options, and much power, at their control. Enough, let the adventure begin... CONTENTS Line Topic ──── ─────────────────────────────────────────────────────── 147 NOTICE 182 LIMITS 210 REGISTRATION 307 DISCLAIMER 317 ACCESS 343 WHAT'S IN A NAME? 365 STARTING UP 429 TRY OUT 528 RESTARTING 589 Ram Drive 643 Config 680 INPUTING 808 Colorizing 842 Censoring 916 Active spelling checker 932 OUTPUTTING 995 CONSOLE KEYS 997 When waiting for a caller 1033 From the terminal program 1050 When a user is on-line 1129 Definable 1167 Misc. 1209 LOGGING 1214 Callers log 1260 Session log 1265 Chat log 1269 Error log 1278 LOGIN 1326 READING MESSAGES 1348 Header 1371 Body 1378 Command Line 1393 Again 1395 Continue message 1404 Delete 1412 Edit 1434 Forward 1455 Get files 1467 Give files 1484 Next 1488 Previous 1494 Reply 1497 View a file attach 1515 User maintenance 1522 Sysop DB 1531 / AI's Go Fish 1542 ? Peer Review 1559 ! Re-Locate 1568 @ Header Edit 1576 ^ Re-Inform 1589 Misc. 1603 ENTERING MESSAGES 1620 Heading Line 1627 In 1634 To 1658 Subject 1672 At 1694 Line numbers 1702 Quote original 1712 Carbon Copies 1722 Upload message 1759 File Attaches 1802 Body 1877 Command Line 1888 % 1896 Abort 1898 Continue entering 1901 Delete lines 1904 Edit 1910 Finish later 1934 Grammar check 1946 Insert lines 1952 List 1960 Preview 1969 Save 1972 MESSAGE FILES 2072 RAMBLINGS 2109 FILE AREA CONTENTS LISTING 2134 Standard 2178 Point & Shoot File Selection and Information System 2240 Paged File System 2331 DOWNLOADING 2453 UPLOADING 2501 Searching 2548 File Descriptions 2586 REMOVING FILES 2648 MISC. 2675 I AM LOST!?! 2704 CUSTOMIZING 101 2727 TOGGLES 3058 SETTINGS 3679 PATHNAMES 4340 CONVERSION 4367 MODEM SETUP 4452 Problems 4489 TERMINAL PROGRAM 4583 SPECIAL THANKS 4588 NEXT Line numbers are useful for such file viewing utilities as LIST. This documentation is not really meant to be printed out. I, myself, never print documentation out--I prefer instead to read it with PC-Write, that way I can delete the stuff I already know, or consider unimportant. DOCS_1.DOC describes how to use the software. DOCS_2.DOC describes how to set up and configure a BBS. MENUCMDS.DOC describe the command system and commands. NOTICE This is not a pre-release, alpha, or beta version. I will be numbering my releases .01 to .99. Each release will always have a couple of bugs, or enhancements that are awaiting the future. I will never consider this software finished. Bugs that do appear, however, can usually be gotten around by the software's great redundancy. I make a great effort each release to test everything for bugs. But there is no such thing as bug-free software. With each release a program approaches that goal. New versions will be released every 1 to 6 months. It is an evolving product. In many cases, the ideas you relay to me will appear in the very next release. If you find any thing not to your liking, please tell me. New ideas need not change the old method, this program is designed to do many same things differently. The key word is "release"--there are no intermediary, alpha, or beta versions. Some releases may only have a couple of important bug fixes, others may include 100k of new stuff. I am basically using the same distribution and release techniques Chuck Forsberg uses with his DSZ product. All registered sysops are notified, by computer mail to their BBS, of a new release--so you will never have to wonder about whether you have still got the latest version. It is ready to run now, just INSTALL it and run it--even if you are running a BBS on COM1, do not worry, it will be in local mode. LIMITS Mostly your RAM and drive space are your only limiting factors, and if you can program, there are no limits. 999 file areas. 100 voting questions. 999 message areas. 32,767 active messages per message area. Message numbers can go to 2,100,000,000. 25 of your own defined data bases. 32,767 door programs. 99 undergoing-peer-review users. At least 999 message files. 32,767 entries in the databases. 20000+ active users. 20000+ active files on-line. REGISTRATION Required within 30 days of use. See ORDER.FRM for pricing information. Registration entitles you to use JDR_BBS for three years. If you are a company, you must do a corporate registration. If you are an individual, you may choose personal or corporate registration. Registration is on a per node basis. Each computer running this software must be registered. A single computer multitasking three phone lines is considered one computer. I have tried to make registration as flexible as possible for everyone. A computer expert will probably not need stuff like voice support or updates, but a corporation would probably find it quite useful. Rather than spreading the cost among everyone, I broke the various extras out of the primary registration package. Upon registration, you will receive a packet containing at least the following: ∙ 1 720k disk, or 2 360k disks, containing the latest registered files. ∙ A 3 key sequence which you'll be able to use to extract the registered files from JDR_BBS.REG when new versions come out. ∙ Confirmation of payment or order. ∙ An account on the Immortality BBS (development site). ∙ Access to the encrypted Registered JDR_BBS net mail echo for technical support. ∙ A message sent to your BBS informing you when each new release is available. ∙ An entry in the list of registered BBS's, which is included with JDR_BBS. ∙ The registered version has additional features and commands. Registration is only for three years. This was done because the registration fee is not near the value of the program-- but I felt a need to keep it affordable. Also because of my continuous-update distribution method (which means you do not pay for each major release like most software.) The disks I send you only contain the additional registered files, they do not contain the complete program. The complete program would require adding another $10 to the registration, which would be unnecessary since the latest version is always on various BBS's. The most weird thing about my registration cost structure is the $10/month voice support. It is structured like this because, frankly, support is the greatest cost besides development. Rather than spread the cost over everyone, I have set it so only those who need it will get it. Also, since I will be doing the support, you will get expert knowledge. The printed documentation contains no more information than the disk-based documentation, but may be more convenient. The updates are replacement pages containing what has changed between releases, keeping old documentation always current. The phone costs to download future releases can be excessive if you are in a remote area. For this reason, I am willing to send complete releases of JDR_BBS by mail at the following rates: $15 for U.S. addresses, $20 for Canadian addresses, and $30 for addresses outside U.S. or Canada. You may order the latest release, or pre-order for the next release. Please specify diskette type. The code is complex enough, that it is cheaper to register and ask me your confusing questions, than to spend literally days or weeks figuring it out for yourself. The Registered JDR_BBS net mail echo is the only way, besides voice, to get specific detailed answers from me to any problems you are having with JDR_BBS. The prices will not change significantly in the future. Even as the program becomes more advanced and more graphics oriented. The prices will, for the most part, only increase at the rate of inflation (2 to 5% a year). By 1995 I expect to only need about one release every six months. │ There will never be a non-shareware version. Although for │ cost reasons I may reduce posting of the source to only a few │ major BBS's around the country. Usually sending cash is safe. For extra safety, you can send it via certified mail. See also: REGISTERED PACKAGE DISCLAIMER I make no warranties of any kind, either expressed or implied, as to the fitness of use, quality, or performance of this software. In no manner shall I be held liable or responsible for any losses or damages arising from the use of this software. See also: NOT_DOCS.DOC ACCESS I can be reached as follows: Physical mail: John Rohner POB 340304 Milw., WI 53215 Electonic mail: John Rohner Immortality (414) 643-1576 Exec-PC (414) 789-4352 Net mail: Immortality (414) 643-1576 Must be direct call. JDR_BBS continuously accepts mail (anytime before a user name is accepted--at the logo or login ANSI, or user name question). Contact me if you have any problems with the software. I am willing to generate special bug-fixed JDRBBS.EXE's for you if you are willing to test that the bug is eliminated. WHAT'S IN A JDR_BBS is the name of this software, always has been. NAME? Starting with .08 I decided it would be nice to give it a "word" name--not just initials. That name is Juggernaut. The full name became: Juggernaut, Dendro-Recominant BBS The first question is always, "What does 'Dendro-Recombinant' mean?" "Dendr-" means tree-like. The BBS and its environments are all tree-like. "Recombinant" means recombined. This software recombines features into one .EXE that many other programs have in a hundred other .EXE's. So, when referring to this software, you should use either JDR_BBS or Juggernaut--whichever you feel less foolish saying. STARTING UP To make full use of this software, you will need the following (listed in order of importance): ∙ The latest version of PKZip/PKUnZip. ∙ Your favorite text editor. ∙ A fossil driver, such as X00 or BNU. ∙ A protocol driver, such as DSZ or GSZ. ∙ An ANSI editor, such as The Draw. ∙ The latest version of ARJ. ∙ The latest version of LHA. ∙ Any version of List and SortF. ∙ You will probably also want the latest version of PKLite or similar (for reducing .EXE's). ∙ The Latest version of BiModem. ∙ A disk defragmenting utility. ∙ You will probably also want Microsoft Basic PDS 7.x. (Only needed if you want to do source modifications.) ∙ You will probably also want Microsoft Macro Assembler 5.1+. (Only needed if you want to do source level modifications.) ∙ A 640k or more computer. Should work on any PC compatible. ∙ A 2400 baud or better modem. ∙ No graphics (yet) so any monitor should be fine-- although a color monitor is really necessary to see ANSI color screens. But once the BBS is set up the way you want it, a monochrome monitor will do just fine. ∙ One or more hard disks. At least 30 megs if operating a multi-user BBS or a floppy for just a node between two friends. Except for Basic PDS, and MASM, all of the above software is available for download from most every BBS. Most you probably already have. If you are just beginning to learn about all this, then X00, SortF, and The Draw are probably the least familiar. They are usually stored on BBS's with the following file names: X00Vxxx.ZIP, SORTFxxx.ZIP, and TDRAWxxx.ZIP--where "xxx" is the version number. If you cannot find any of the software on your local BBS's, then give mine a call and you can download it from there. In the future I will be porting the program over to Visual Basic and Windows as well. The software has been tested with SuperStor 2.0 drive compression software. It works fine, but with a dedicated computer as your BBS, the disadvantages outweigh the advantages. The disadvantages: slow file moves, more uncertainty about testing programs (doors and uploads), and limited disk enhancement utilities that can be run on their own as events. The advantages: more drive space for door programs. But the advantage is not true. PKLite your door .EXE's and you will do better. Why? Because doors have lots of little data files--and the minimum file size with SuperStor is 8192 bytes (each file/dir uses at least that). I have been told the software works fine with DesqView and Windows, but I have not personally tried it out. TRY OUT Just run JDRBBS.EXE. It is configured with comm port = 0 (local/console) so you do not have to worry about hooking up a modem/etc. to try it immediately. It will use the current drive as its basis drive, and will initialize the #NEWUSER new user record (the first user record). The software keys on the existence of PATHS.DAT to determine when you first run it. It then creates PATHS.DAT, BBS001.BAT, DOOR001.BAT, and BACKUP.BAT. It also sets the comm port to zero, re-initialize's #NEWUSER to the default settings, and sets the waiting-for-caller drives-to-show to the current drive. Finally, it goes through all your small SYSTEM\*.DAT files and changes "C:\" to whatever your current drive is, and similarly for BLOCKS.TXT. It does the same change for all occurances of "System Operator" with whatever name you give it. That is all. Which means if you accidentally delete PATHS.DAT, you do not have to fear for the rest of your files. Because it is set for local-only operation (Comm port = 0), it will automatically display the logo and start the login process. Follow what it says. It is just like logging onto a normal BBS. Logon with your name. One thing you will notice immediately is that instead of "password:" I use "verification:". You can change it if you like. "Password" was just too archaic for me. After all, "my pass word", "]I[ %5^&890", and "643-1576" are all valid, and hardly a word. Now that you are in, play around with it, get to know it. I have pre-created the following for you: 1 files area: UPLOADS a few message areas 2 doors: ED.EXE (PC-Write) CSHOW.EXE (CompuShow) 7 voting questions 1 ramble 8 security levels Some sample MESSAGE.xxx files. 3 Directry files: Unprotects Music Quotes Other Ansi's Some other minor/sample stuff. This is so you can get some general feel for the software and its capabilities. For the file area related commands, you might want to put a file or two in the uploads area to get a feel for what things look like. If you do, their descriptions will be "?" until you give them one. If any of you design a much simpler BBS, send me a copy of your files. I will try to include about 5 different "flavors" of what can be done in future releases. After looking around, hit <alt>u, then enter your name. This is the user maintenance--change your security level to 100. Hitting "!" at the main menu brings up the sysop menu. At the sysop menu, hitting 1, 2, 3, 4, or 5 selects the sub- menu wanted. Bring up the configuration menu (4). Now you should make sure the .EXE and/or paths are correct in the following instances: Alter Pathnames Door Maintenance File Areas Protocols Finally, under Change Settings, change your Net Address (if you have one) and your Phone Number to your own. Then change Hub Address (if you are part of FidoNet) to the Address of your local Hub (or the hub of whatever net you use most). Do not worry about the communication parameters for now. You may quit the software by hitting <alt>x. In some cases I mention the menu option (eg. "New Stuff") when talking about something, sometimes I mention the menu command (eg. "NewS"), and there may even be times when I mention the actual module name (eg. "NewStuff"). Just stick with it and remember that they are just names. I have tried to use merely descriptive text (eg. "listing of stuff that is new to the caller") but sometimes I regress. See also: CUSTOMIZING 101, CUSTOMIZING 201, MODEM SETUP, CONFIG, SETTINGS, PATHNAMES │RESTARTING After the first time, always use "BBS001" (as in BBS001.BAT) │ to run the BBS. Or rather BBSxxx where "xxx" is the node │ number you wish to run. If using only one node, it is easier │ to just copy BBS001.BAT to BBS.BAT and just type "BBS" to run │ the program. I have bundled SHROOM with this release to give the software swap-to-disk capabilities. You should unpack the ZIP. In a future version I will use my own swap-to-disk routine. If you do not do any "_shrink" door exits, then you need not use SHROOM. You may use JDRBBS /? (or BBS001 /?) to bring up a list of what "/" command-line commands are available. They are: /? to get a help list. /BIOS to toggle usage of BIOS/direct screen writing ON and OFF. /NODE=x to start up node x. Where "x" is a number from 0 to 999. /PORT=x to re-set the current comm port to x. Where "x" is a number from 0 to 4 (or higher if your fossil supports it). /MODEM=x to reset the current comm port's baud rate to x. "x" is one of: 1200, 2400, 9600, 19200, or 38400. It is the speed at which the software talks to the modem. /LOG=x to change the current LoggingAmount. See SETTINGS. "x" is one or more digits (0 to 9) and one or more of "A" to "F" letters. /1STCMD=xxxx to re-set the first command to xxxx. "xxxx" must be a four letter command. You may run a single command by doing: JDRBBS /1STCMD=xxxx BBS001 /1STCMD=STRT the first part runs JDRBBS and executes the command "xxxx", the second part re-sets it properly. "xxxx" should not be a command that requires the user's name unless you put a "LogN" as the first command in "xxxx"'s command list. Your "xxxx" command must be all upper-case (that is, "doAB" is no good, must be "DOAB"). Probably "/MODEM=0" then "/MODEM=n" needs to be done for some commands--otherwise it exits because it does not find a carrier on the currently defined port.. Each command must have no spaces within it. So "/node = 1" will not work, nor will "/log=1 3 567". For the most part, the /BIOS, /PORT, /MODEM, and /1STCMD commands are meant to get yourself out of a jam when you accidentally define them wrong when running the software. Ram Drive The system will make extensive use of some files. For this I recommend you define a RAM drive. There are two inter-linked path's that relate to operations of a RAM drive. When in "Alter Pathnames", they are the "Files to go to RAM Drive" and "RAM Drive" entries. For distribution, I have set the "RAM Drive" path to d:\BBS\NODE.???\RAMDRIVE (that is, the same as "Files to go to RAM Drive"), so until you change it to a real RAM drive the system will be really dragging. Since most of the text is stored external to the program itself. But there is no need to do this unless you actually wish to use the software, for evaluation purposes only; it is not worth the hassle. The reasons for using a RAM drive are fairly obvious. Those files most called will get loaded and sent faster. This also reduces wear and tear on the drive itself. The reasons for putting text in a RAM drive file is not so obvious. The quick answer: Basic has a limited amount of string space, text is strings, putting it in a file frees up string space. But there are some other advantages as well: the text is easily modifiable, internally the program is easier to understand--which leads to improved optimization with the remaining code, a RAM drive can be put anywhere-- regular memory, expanded, extended, or on disk--allowing for more flexibility by keeping the .EXE smaller and the "real" RAM used by the program much smaller. Yes, there is a slow down--not noticeable at 8 MHZ, trade- offs are a fact of life, and this was one of them. If you have something like: Files to go to RAM Drive : C:\BBS\NODE.???\RAMDRIVE\ RAM Drive : E:\ Then at start-up, every file with "C:\BBS\NODE.???\RAMDRIVE\" as its path will be changed to "E:\". This is done internally. So, using "C:\BBS\NODE.???\RAMDRIVE\" is the same as saying the file is on "E:\", that it is on the RAM drive. Unless the two fields contain the same path, "C:\BBS\NODE.???\RAMDRIVE\" is never really accessed. Since all the files are on "E:\", it is "E:\" that is always accessed. See also: PATHNAMES Config Below is what my config.sys and autoexec.bat look like: CONFIG.SYS: buffers = 25 files = 20 device = x00.sys B,0,19200 T=4096 R=4096 eliminate device = ramdrive.sys 45 AUTOEXEC.BAT: set dszlog=c:\bbs\dszlog break off verify off cd \bbs │ The X00 line above defines COM1: with a locked DTE baud rate. │ If you do not need to lock your baud rate (such as with most │ baud modems) use: device = x00.sys eliminate │ The X00 also has "T=4096" for a transmit buffer of 4096 bytes │ and "R=4096" for a receive buffer of 4096 bytes. X00 │ defaults to 512 byte buffers, but larger buffers are useful │ with MNP connects and do speed things up a little. You may also use a disk cache--it will help--but wait until you have the BBS working as you like it. Since if it crashes, you lose whatever is stored in the cache. Also note, DSZ recommends you disable your cache before running DSZ. │ Turning "break off" and "verify off" is an old BBS'ers trick, │ allowing faster disk accesses. Not recommended for iffy hard │ drives. If you just want to look around--not run the BBS, just ignore the CONFIG/AUTOEXEC stuff. INPUTING In most cases inputing of file names and user names utilize "auto-completion"--you start it, the software finishes it. With every keystroke, when entering a file or user name, the software searches through all entries and looks to see if there is only one possible keystroke for you to make next (when you are not allowed to type a filename that does not exist, or users that do not exist). The software will then send the keystroke out--saving the user the need to type it. Similarly if only one file or user name is possible. When entering user names, matching is not done until the second character. This is done to speed up reaction--since the first character usually has a lot of matches. Not necessary for file names because they use a different type of search system (all or nothing for file names, all or whatever is typed for user names). When entering user names, you may type a "*" or a "?" anytime after the first character. When this is detected, a list of all the users matching those letters will appear. Example: typing JOHN* would show all users with names with the first 4 letters "JOHN". This is mostly useful for when entering messages TO a person in a message area that allows any TO name (thus no auto-name-detect). Some answer fields, that have a size limit, automatically do a [Enter] when you reach the end of the field. Phone numbers detect whether it is a local or long distance number (United States/Canada format only, for now). If users complain that they cannot enter a number they want, they are entering a "1-" number, or an international number (which I do not support yet) or a bad phone number. Security levels, in some places, can be entered by entering a range--either a single value, or two values separated by the word "to" (eg. "5 to 20"). In most situations, a [Space] (or [Tab]) will pause the text, and an [Enter] will cancel or exit an option. [Tab], when reading messages, will pause the message, but when at the reading messages command line, it will act like a [N]ext command. I did this in response to some complaints that users wanted the [Enter] key to act like a [N]ext command--it seems beginners who cannot touch-type do not like the idea of searching around for the "N" key. With one of your most powerful fingers 1/2 inch from the "N" key always, and with the [Enter] key requiring a weak pinky and 10 times more pressure, I am not going to make the [Enter] key a [N]ext key. That kind of poor design only increases the speed of your getting carpal tunnel syndrome. For times, a 24 hour clock is assumed. This means that an hour of "0" is midnight, "12 is noon. A day starts at "0" (midnight) and goes through to "23" (11 pm). Because of the way seconds are stored, they may be off by one second from what you entered. A 00:00:00 to 00:00:00 range means available 24 hours (indeed, any two matching times mean to use the full 24 hours). For 24 hour restriction, use 00:00:00 to 23:59:59. You must enter the full 8 characters (HH:MM:SS) or you will get random results. When entering a description or a message, the following keys, when typed, will produce the result. Keys Resulting Entered Character ─────── ───────── a"a ä e"e ë i"i ï o"o ö u"u ü y"y ÿ A"A Ä O"O Ö U"U Ü a`a à e`e è i`i ì o`o ò u`u ù a'a á e'e é i'i í o'o ó u'u ú E'E É a^a â e^e ê i^i î o^o ô u^u û n~n ñ N~N Ñ a.a å A.A Å c,c ç C,C Ç ?^? ¿ !^! ¡ With the exception of the last few commands, you type: 1. character you want 2. character above the character you want 3. character you want The BBS will then delete these three characters and replace them with the foreign character. When a user receives a beep, such as during active grammar check, or after file transfers, the console will not get the beep (to preserve sysop sanity). When entering drive paths or pathnames, you should always specify the "d:\" at the beginning. If you are the sysop, then most of the "inactivity time-out" timers will be ignored. Colorizing When entering the body of a message, or file descriptions, you can use special coding to give color to a word or a phrase. There are two codes: " }xword" and " ]xtext[ ". In both cases, the "x" represents a number: 1 Bright blue. 2 Bright green. 3 Bright red. 4 Bright violet. 5 Yellow. 6 Bright white. The rules: There must be a space before either the "}" or the "]" symbols. There must be no spaces between the "}" or "]" and "x". There must be no spaces between "x" and the word or text. The "[" must come immediately at the end of a word (no space before it). "}x" combinations are used to colorize a single word. Example: " }3Hello }6Johnny. }1How are you?" "Hello" would appear bright red, "Johnny." would appear bright white, and "How" would appear bright blue. "are you?" would be the normal brown if a message, or blue if a description. "]x...[" combinations are used to colorize phrases. Example: " ]3Hello Johnny[ ]1How are you?[" "Hello Johnny." would be bright red, and "How are you?" would be bright blue. Note that the block color method works across message lines. This means you can start it on one line, and end it on another. With all text in between becoming whatever color you select. Censoring This software has the ability to "censor" user inputed text. This censoring is done only when entering file descriptions or the body of messages. There are three "levels" of censoring: simple case adjustment, removal of non-words, and removal of superlatives. All three are done when entering file descriptions, and only the first two are done when entering messages. Censoring is not done on imported or uploaded messages. It is also not done when importing file descriptions. You, the sysop, may toggle on/off this feature. You may toggle removal of non-words on/off and you may toggle removal of superlatives on/off. If both are toggled off, then case adjustment is also off. If either one is toggled on, then case adjustment is also on. Simple case adjustment is the "correcting" of lower case to upper case. Examples: " i " becomes " I ", "bbs" becomes "BBS", ".gif" becomes ".GIF". Removal of non-words eliminates the word completely. The words that are eliminated: "alot", "l8tr", "c00l", "k00l", "gotta". Removal of superlatives eliminates the word completely. Words that are superlatives; excellent, great, super, incredible, etc. are removed. All three are done as the user enters the text. Case adjustment is the only one that is not "demonstrated" at the time. By demonstrated, I mean that when a user enters a non- word in either a message or description, or a superlative in a description, then they will see the word deleted before their eyes--no matter how many times they repeatedly enter it. Of the above, the "alot" elimination seems to have caused the most trouble--those who use this non-word seem to have trouble stopping themselves. Why censor superlatives? If you are an experienced sysop, you know. Users will always try to add a superlative in their descriptions, they seem to feel the "need" to "sell" the sysop on the upload, this is particularly true of systems where the upload must first be validated by the sysop before others can download it. One can get tired of them quickly. This is one of my favorite features of this software (the other being automatic logging of removed files). Description censoring is not done when the user is the sysop. You may add or alter the various censored words. In SHORT.TXT they are organized as follows: 0001 to 0039 Superlatives, must be ordered by size--smallest, then increasing in size. Words are censored if their first x characters match one of these words. 0040 to 0049 Are "non-words". Words are censored if their first x characters match one of these words. For positions where numbers may appear, use a space. 0050 to 0064 These are "to be upper cased" phrases. If the last (or right) x characters of the word being checked contains these characters, than these characters will be replaced with their upper- cased version. Example: "dsz.com is not a gif." would become "dsz.COM is not a gif." ".com" matched the right side of the word "dsz.com", but "gif" did not match the right side of "gif." Active Active spell checking is a form of censoring. While entering spelling messages, it beeps whenever a word you just typed is not checker found in the word lists. It beeps at the same misspelled words that Grammar Check would highlight. If both removal of non-words censoring and removal of superlatives censoring are turned off, active spell checking will not operate. If you do not want censoring, but want active spell checking, then leave one of the censors toggled ON, and clear out the SHORT.TXT entries for it (so it finds nothing to censor). Active spell checking can be turned on and off by the user, but it still requires that you have censoring ON to work. OUTPUTTING There are a couple of ways for BBS programs to display output. One is to display everything to the local (console) screen first, then send it on to the remote screen all at once. This is the fastest method, but it does not allow output to be interrupted (such as for hot-keys). Either this method is common, or a lot of BBS programs do not handle it properly. When using the terminal program in this software, it has special coding to defeat these poorly designed BBS's by not wasting time displaying all the extra text. Another method is to display everything to the local screen, then send it to the remote screen and watch for input after each character. This has the disadvantage that sending and waiting each character is slow. Another method is to output fixed length packets to the local screen and remote screen, checking for incoming keys after each send. This is good, but... Another method--that I use--is to output variable length packets to the local and remote screen, checking for incoming keys after each send. I use the ASCII 27 code (ANSI code signal) as the "packet breaker upper". Besides the last method, there are times when I also output a character at a time and check after that. This is done for the "SendTT" text, in which lines may only have ANSI codes at the start, and do not require a lot of speed anyways. I also add a farther delay: character pacing. The next character or packet to send is not sent until the fossil's output buffer is empty (signifying that the character(s) have been sent). If I did not do this, then the modem or fossil's buffers would put us right back at square one--fast massive output, with no input character checking. Similarly for actually displaying characters, there are multiple methods: The slowest method is to use the screen writing routines that came with the language itself. The safest method is to write assembly routines that route characters directly to INT 21h (DOS functions) to do the displaying. This is the non-BIOS method I use. A more risky, but faster, method is to write assembly routines that route characters directly to INT 10h (BIOS functions) to do the displaying. The fastest, but most limited, method is to write directly to the screen's memory itself. This is known as "direct screen writing". I use this, and some INT 10h calls, for my BIOS screen writing option. It has the disadvantage that it does not work in graphic screen modes (such as multi-window modes, etc.) But for normal 80x25 screen modes, it is the best to use. See also: SETTINGS, TERMINAL PROGRAM CONSOLE KEYS When waiting + to view the next help page. for a caller - to view the previous help page. <f1> toggles the trapping of all comm I/O to a file. <f2> toggles the trapping of all chat to a file. <f3> toggles whether you are available to chat. <f5> toggles the drive space/memory info pages. <f6> toggles screen blanking. <f7> toggle between help screens and sysop info. <f9> to logon locally. <up> to view the previous callers log page. <down> to view the next callers log page. <pgdn> toggles the trapping of all comm I/O to a file. <alt>a to alter the system settings. "ASet" menu command. <alt>d to use the terminal program. Whatever you type, an "AT" will put tacked onto the front of it, and the command sent to the modem. After your "session", whether it be just sending a command to the modem or a session on another BBS, you will need to hit any key to continue, as the system pauses so you are able to see the results of what you did. See also: TERMINAL PROGRAM <alt>f to do file maintenance. "File" menu command. <alt>p modem command line interface. Useful for debugging modem problems. Just like any communications program modem command line. Can be used to dial out, <alt>p again to exit this mode, <pgup> to upload a file, <pgdn> to download a file, <alt>s to shell to DOS. <alt>r to remove a file. "RemF" menu command. <alt>s to shell to DOS. <alt>t to change the toggle settings. "Togs" menu command. <alt>u to do user maintenance. "User" menu command. <alt>x to exit to DOS. From the <f1> toggles the trapping of all comm I/O to a file. terminal <f2> Send a file (ASCII send--no protocols). Can use program wildcards to send a random file from a bunch of files. No stop/exit key handling is done. <pgup> to send a file. Upload to the BBS you called. <pgdn> to receive a file. Download from the BBS you called. <end> to transmit any netmail meant for that BBS. You must have dialed with a "d string" command for this to work. <alt>h to hang up. <alt>s to shell to DOS. <c><left> <control><left> This will send an ASCII 27. It is expected that you will follow up this key with a valid ANSI string--none of which will be displayed. When a user <f1> toggles the trapping of all comm I/O to a file. is on-line <f2> toggles the trapping of all chat to a file. <f3> toggles whether you are available to chat. <f5> toggles sysop-on-next status. <f6> toggles screen blanking. <up> to increase their session time by 5 minutes. <down> to decrease their session time by 5 minutes. <left> to decrease their SL by one level. <right> to increase their SL by one level. <pgup> Send a file (ASCII send--no protocols). Can use wildcards to send a random file from a bunch of files. No stop/exit key handling is done. <pgdn> toggles the trapping of all comm I/O to a file. <esc><esc> hang up on the user. Hitting a single <esc> waits for you to type another key--even if the user hangs up (they can no longer type keys). After hitting one <esc>, any key besides <esc> will "unstick" the waiting of keys and everything will be normal. <alt>b to beep the user. <alt>c to chat with the user. Hit <esc> and then c to exit chat. <alt>h hang up on the user. <alt>p modem command line interface. See above. <alt>s to shell to DOS. Output is not sent to the user. <alt>u to do user maintenance. "User" menu command. The caller does NOT see anything, and any keys the caller types are executed after you exit the user editor. You can make changes to the current caller, or any caller, and those changes will be immediate. <alt>x to do an immediate exit to DOS. This does not save anything. It only works when you are logged on at the console. <c><left> <control><left> This will insert an ASCII 27 (arrow) into what you are editing (such as message, message title, etc.). You must then continue with "[" and then a valid ANSI sequence-- none of which will be shown, but it will take effect and is stored. Example: <ctrl><left>[37m is the ANSI sequence "" which is white color. <up>, <down>, <left>, <right> are session only commands, their effects are not permanent. If the user is logged in at the console, they will not be able to do this, these keys are then used to move around places. <alt>s and <alt>c will interrupt what is currently being done, and either shell to DOS or enter chat mode. When done, you may need to hit return to redraw the screen--if you did the commands while a menu was being displayed. Usually you will not want to hit these keys at anywhere else besides menus because it can cause confusion--both for you and the user--especially if you do it while they are about to enter a file description. The key to remember: that wherever you interrupt the user, the <enter> you type will be handled as if the user typed it. Increasing the SL allows you to do sysop things from the console while another user is on-line. It also allows you do demonstrate the sysop capabilities to another user. When adding or subtracting time, you are actually subtracting or adding, respectively, to their "elapsed time used today" total. The changes are not permanent. A negative number will show up in their user profile for "time elapsed" if you gave them more time than their daily limit. Since total time available is calculated by subtracting elapsed time from daily allowances. When you are in a DOS shell (such as using <alt>s--which can be used from Chat as well), two useful commands are: "DSZ rz" and "DSZ sz filename.ext". The first receives files the person at the other end is sending, and the second sends "filename.ext". Both assume comm port 1, and you may need to change to the directory with DSZ first. See also: THE "WHO'S ON" STATUS LINE Definable You may define <ctrl>F1 to <ctrl>F10. Lines 0851 to 0860 in SHORT.TXT correspond to F1 to F10, respectively. These lines should contain a 4 letter menu command that you wish to use. These control sequences will be allowed from anywhere. This is an extremely powerful, dangerous, and unpredictable ability of the software. It relies on you to know when a menu command should or should not be executed--especially so when a user is on-line. They are probably best used to call a door from the waiting- for-caller screen (hint hint). Because you may enter any menu command, and do the command at any time, you can see how problems can arise. Particularly important to not do: user commands when no user is there for the software to find or update. Only trial-and-error will let you know when to use that key to do what you want, and when not to (ie, the system crashes). I have predefined <control>F1 as the door to ED.EXE. I have predefined <control>F2 as the MCED command. Very useful when you design yourself into a hole in your menus. Some commands probably will not work if the current comm port is not zero (because the software does not detect a carrier signal on the current port). I will fix this in .09 by creating a menu command "PORT _xxx" which switches to another port (such as 0 which means local). See also: MENU COMMANDS Misc. The way the program works is like a hub and spoke system (such as a large city in relation to the smaller cities around it). Menus represent the central hub. From these you go to many sub commands. This means that most commands are sub commands and not part of the main hub. So, for safety's sake, you should only execute console keys (such as chat, or <ctrl>Fx's) from the menus when a caller is on-line. The concept is that you can go to the sub commands from the main hub, but you should not jump from sub command to sub command directly. For you programmers: even though Basic has re-entrant capabilities, exploiting them by jumping from sub to sub without going through the central hub (Dispatcher) could conflict with the global variables and distort them. The "dinky" stuff, such as <esc><esc> or beeping, you should not worry about. It is the chatting, shelling to DOS, running a door, etc. that are likely to cause troubles for you if you execute these "inside" a sub module. You can do a <pgup> "send them a file" while a menu ANSI is being displayed. After your file is sent, the entire menu ANSI is re-drawn. It's an example of Basic's re-entrant ability--since both displaying the file and key-checking is handled by the same routines for both options. When displaying the ANSI it calls a checking routine--which finds that you want to send a file, it then calls the file display routine (which is the same routine that did the key checking originally) to display the file (it will then call the key checking routine also). As you see, it can be very recursive--I hate recursion and consider it risky, but it does seem to work ok. LOGGING Both the Callers log and the Errors log can be limited in what they show using the setting for "LoggingAmount". See also: SETTINGS Callers log This has the file name CALLERS.LOG. The callers log contains 3 types of data lines: user, file, and system. The system lines all start with a "|=", and contain informational messages from the BBS to the sysop. Users cannot see these lines. The user lines begin with the date and a user's name. For all users to see, it is mostly who logged on when. The file lines come straight out of the protocol log files. They do have any paths stripped out before being added. When listing the log, users are shown the user lines and the file lines. When the sysop lists the log, he is shown all lines. From the information shown, users can deduce the following: ∙ Who called, when, and from where. ∙ Who upload files--in case they would like to contact the uploader with a question. ∙ Who downloaded files--to see if a friend downloaded a file (saving them the trouble) or to see what kind of download interest their own uploads have gotten. ∙ Who lost credit for duplicate/bad uploads. ∙ Who passed, or failed, Peer Review. It is also useful for other sysops, they can see who are good users and who are bad users. Perhaps leading to increased access for these good users on their own board. File attach transfers are logged with see-able or not see- able lines depending on how that file's file area is configured. Note that when you list the log using an external list utility, that the user who did the actions comes after what they did. That is, when using something like LIST, the user that did a file transfer is listed after those file transfer entries. The file should be read bottom-up. When using one of the software's internal log lister's, this is taken into account and is listed correctly with the person's name first and their actions on the following lines. Session log This has the file name SESSION.LOG. Contains the I/O exactly as it was sent--including all the ANSI or Avatar codes. Chat log This has the file name CHAT.LOG. Contains the trapped chat sessions. Error log This has the file name ERRORS.LOG. This log contains important error messages, or unimportant minor adjustment notices. When you have a problem, you should check here first to see if it might have helpful information. LOGIN When logging in, a caller may start their name with "=". Example, "=John Rohner". What "=" does is disable auto-name- detection. This is useful for users that use scripts, since with auto-name-detection their "key sequence" that makes up their name, may change from login to login if a similarly- named user is added, or deleted, from the user list. Auto-name-detection at logon always gives me a good chuckle. This occurs when a new user calls the second time, and types their name, with the software producing half of it. They just pause, and you feel the disbelief they are undergoing, "How the heck did the BBS know that...". If the caller just hits [Enter] for their name, then auto- name-detect is immediately turned off (without bothering to tell the caller). If the caller just hits [Enter] for their password, and it is not their password (yes, passwords can be nothing) then the software jumps to auto-name-detect-off name entry. If the user has defined a logon note, it will be shown during the login process. The callers minutes-left-today statistics will then be shown. If the caller has any unread mail waiting for them, they will be given the option to read it at login. By default, a "do not read now" is executed if the user just hits [Enter] to the read-mail-now question--for those with overly anxious fingers (so they don't hit [Enter] accidentally just as the message starts displaying--when they were just slamming [Enter] to get to the main menu quicker). If the caller has multiple messages waiting, they may select to Scan the messages (hitting "s") which gives a single line of information about each message waiting for them. The login process can be defined as the session from the moment of connect to when the primary menu is reached. At any point during the login process, the sysop may define that one or more ANSI's be displayed. They sysop may also add or delete various other capabilities (such as news) that can appear during the login process. See also: MENU SYSTEM, LogN, Welc, STRT READING When you select a reading messages command from a menu you MESSAGES will be given the range of message numbers and the number of new messages. You will be asked to enter a message number to start at, or type "N" to start at the first new message. The exception to this is when logging in and reading Private Mail (if you are not a message-op), then it just displays the first appropriate message to the command (such as first new, or first to/from the sender, etc.). A message is then displayed. After the message is a command line where the software waits for you to type your next command. The user may set a toggle to decide whether the command line should come after each message, or only messages to/from them. By turning the toggle OFF, the user is basically doing a continuous message reading. When reading the text body of a message, you may type any of the command line keys. "N" for "next message" is particularly useful when doing a continuous mail read. Header Users have a toggle which they may set ON to tell them the number of lines in that message. If there are less than 10 lines in the message, then the number will not be displayed. In addition to line count, the following are toggles that a user may turn on/off: Showing the number of replies the message has. Showing the number of times the message has been read. Showing the date the message was last read. If the sender or receiver of the message is no longer a user; this fact will be displayed. If the message base has a NET attribute, and the net address is not zero or your's, than the net address will also be displayed. Messages have a counter that is updated each time the message has been read. When the message-op of the area reads the message, however, the counter is not increased. This allows you to, say, review Private Mail without a user wondering why his private message says "read 2 times". Body A message area toggle may be set to show "hidden" net information for NET messages as well. The information then shown is: The NET attributes that are ON. Hidden "Kludge" lines. Such as PID and MSGID. EchoMail/Conference Mail origin, tear, and seen-by lines. Command Line The commands below will not be listed if the user cannot do them. A number may be entered. This is a "jump to number" order. The active message in the current message area that corresponds to that number will then be displayed. If no message has that number, then the first message with a higher number is displayed. Auto-detect for ZModem and BiModem uploads is also done. Unlike the entering messages command line, the uploads are not automatically assumed to be file attaches, the software will exit reading of messages and go to the menu, where it will then accept your uploads into upload area 001. Again Read the same message again. Continue This command will only appear for the author of the message, message and only if they selected "Finish later" to save the message. This command will allow them to continue the message as if they had never stopped. It jumps them right back into the entering message text system. See also: ENTERING MESSAGES Delete Delete the current message. Only the sender, receiver, or message-op may do this. The message base must not have the DEL attribute ON. When you delete a message, it is still there until you purge it--a flag is merely set in the message's header. Edit You may edit/alter an already sent message. It is simple search and replace. You give it a string to search for, and a replacement string, and it does it. For historical accuracy, the replaced text is never "really" replaced. Editing gives you an opportunity to clean up a message. But it also offers an opportunity to "rewrite" what you said. To stop any kind of abuse, what is done is the original text has a backspace character after each character- -too fast to notice when reading, but noticeable in backscroll/capture buffers. Example, I have the message "Howdy, thar!", and decide to edit out "thar" and replace it with "there". When reading, it is seen as "Howdy, there!", but in the backscroll buffer you might see it as "Howdy, t▓h▓a▓r▓there!" depending on what type of communication program you are using. Historical accuracy is maintained, while giving the ability to alter already-sent messages. Only the sender, receiver, or message-op may edit it. Forward You may forward the message being read to another message base or another user. A note, "Forwarded from" is added to the top of the message. A sub-note may attached to the top or bottom of the message. This is useful for explaining why the message was forwarded, or too add a comment before sending it onto the next person or message base. Only the sender, receiver, or message-op may forward a message. The message base must not have the DEL attribute set. Message base attributes, such as ANON or ALL, are ignored. If the message has normal TO/FROM fields, then if moved to a message base with those special attributes, will still contain the normal TO/FROM fields, rather then be given the "FROM: Anonymous" or "TO: Fellow Sentient Beings" to which that area normally demands. Get files This option appears when files attaches exist for the message. It does not appear for the author of the message. This option is used to download those file attaches. The files successfully downloaded are subtracted from the user's can-download bytes and daily time stats. If there is only one file attached, it will begin sending it. For more than one attach, it will ask you for a file name of one to download. Give files This option only appears when "files are attached" was selected when entering the message. It also only appears for the author of the message. The author can use this command to continue or add to the uploads related to a particular message. This command is mainly useful for finishing <incomplete> file attaches. A "continue message" for file attaches. The files are subtracted from the user's can-download bytes and daily time stats. This is done for all the files attached to the message, and regardless of whether one or more of the files were successful or not. That may sound strict, but it helps discourage use of the file attach system as an upload system (for interpersonal uploads). Next Read the next message in the message base, or move onto the next message base if reading mail at login or using the "Read All New Mail" command. Previous Read the previous message in the current message base. If reading mail at login, or using the "Read All New Mail" command, and there are no previous messages, it does not go to the previous area, but exits the reading of messages. Reply Enter a message,a reply, to the sender of the current message. View a file This option appears when files attaches exist for the attach message. This command will display the file. Nothing fancy is done, it simply sends the contents of the file. This is extremely useful sometimes. It allows a user to post a message greater than 100 lines. You could maintain a small library of text files in a message. Disadvantages with this are that you cannot quote from the file, and it relies on the formatting of the file rather than then internal word wrapping/etc. formatting stuff. If there is only one file attached, it will begin showing it. For more than one attach, it will ask you for a file name of one to view. User This brings up the user modification screen, allowing you to maintenance modify any users record. Only the sysop may do this. See also: User Sysop DB This takes you to the Sysops database. Here you can add/modify/list/delete the entries in your "who is a sysop" database. Convenient for when users tell you in messages that they are sysops. Only the sysop may do this. See also: DATABASER / AI's Go Fish This sends the user a quoted reply of their message, and adds a note that they should look for the information themselves. The message is sent from the AI. The original message is deleted. Only the sysop may do this. The text of the reply is stored in BLOCKS.TXT block number 7. You may edit it to your liking. ? Peer Review This command will send the message to a special message file, delete the message, and then send a prepared AI reply message to the user. The user "undergoing Peer Review" attribute (bit "0") is also turned ON. Only the sysop may do this command. The special message file is a Peer Review MESSAGE.Pxx file, from which users participating in Peer Review will get the information to make their voting decisions. If you execute this command when the user already has a Peer Review file, then this message is appended to that file--to provide further information for reviewers. See also: SETTINGS, PEER REVIEW ! Re-Locate This command "moves" a message to another message base. Essentially it is forwarding but without the "forwarding note" etc. It is only for the sysop. The message will be given the next message number appropriate to that area. @ Header Edit This command will allow editing of the header information for the message. Header information includes things like: to/from/subject fields, attributes, net addresses, and statistical counters. Only the sysop may do this. ^ Re-Inform This command is available only to the sysop. It is also not shown on the reading mail command line. This command will "re-flag" the user of the TO: field telling them they have a message. This command is useful after you have accidentally deleted your USERMSGS file--since rebuilding it sets all pointers/etc. to zero--this should be used on all "(Rcvd: -NO-)" messages. It is mainly only used for when something goes wrong. But you can pester the user by re-sending a message they may have ignored also. Misc. If the sender of the message had included file attaches, and you respond with "Peer Review" or "AI's Go Fish", than these file attaches are deleted as the original message is deleted automatically. Header Edit, Continue Message, Edit, Forward, and Re-Locate all will correctly move the original message's file attaches when the new message is created. When displaying the body of a message, [Tab] can be used to pause the message. When at the command line, [Tab] works like the [N]ext command. ENTERING Leaving messages is a two step process. The first step asks MESSAGES you about the message attributes: subject, etc. The second step handles the entering of the message text, and the various entering messages commands, most notably: saving. During this first step, entering of information, you select the first letter of what you want to do/change, and then [Enter] alone to move on to entering the message's text body. Allowable commands are: In, To, At, Subject, Line numbers, Quote original, Carbon Copies, File Attaches, and Upload message (you type only the first letter). Some of these options may not work--either because of the type of message, type of message area, or with each other--then the key will not be allowed, and possibly an informational note will be displayed when they try that key. Heading Line The first thing displayed is a heading line. This line contains information about the type of mail to be sent: Public, Private, Anonymous, and Net. Because there are only two types of "From:", the posters name or Anonymous, there is no "From:" field shown. In This is the name of the message area to which the message is being posted. This command option can be used to re-locate the message to a different message area. Only those message areas which the user both has toggled ON, and access to, are offered. To To whom you wish the message to go. For replies, this is given the name of the poster of the original message. If the message area allows it, "All" can be used. If the message area is an EchoMail or NetMail area, then any name be entered, otherwise the name entered must be that of an active user. Entering "Sysop" will expand out to the message-op of that area. Entering "Fellow" will change to "All", which then changes to "Fellow Sentient Beings". Note: If you do not want "ALL"'s to become "FELLOW SENTIENT BEINGS", then just replace all occurrences of "FELLOW SENTIENT BEINGS" in LINES.TXT and SHORT.TXT with "ALL". Be sure to notice, and keep, proper case (eg. "All" vs. "ALL"). Similarly if you want something other than "Fellow Sentient Beings" (like "Friendly Computer Users"). You may use "*" or "?". This will bring up a list of the first 18 names matching the characters you have entered so far. Subject The subject of the message. For replies, this is forced to be the same as that of the original message. The subject field of a message is a variable thing--it depends on the type of text you type. This is because the message subject's text is compressed. If you type a long subject, and the system "deletes" characters at the end of it after you hit [Enter], then you know some of subject has just been deleted because it turned out to be too long. All subjects have any leading spaces trimmed off. At This is the NetMail address to send the message to (if the area is a NetMail area). Hit a "?" to get some help on what to enter. Merely hitting return will set it to zero--making it a local- only message. The net address format is xxxxx:yyyyy/zzzzz. Where "xxxxx" is the zone number, "yyyyy" is the net number, and "zzzzz" is the node number. But you can type "x.y.z" or "x y z" or most anything and it will work. The software uses your net address to fill in any missing information. That is, if your address is "a:bbb/cccc", then entering only "##" will be converted to "a:bbb/##", and entering "##/##" will be converted to "a:##/##". A private message without a net address in a Private NetMail area will be, instead, correctly put into Private Mail area (001) instead. Line numbers This toggles ON/OFF whether you wish to see line numbers at the start of each line when entering the message text. It is very tricky to edit a message without line numbers. But turning line numbers OFF allows one to put more text into a message, and makes ASCII sends (from caller) of text more reliable. Quote original This will quote the entire original message when doing replies. When entering the body of the message, you may then use Delete to remove any quote lines you do not want, and Insert to insert between quote lines if you want. You cannot upload a prepared message and quote the original at the same time. Carbon Copies You may send multiple copies of private messages to many users. These are known as CC's. When you save the message, the software will ask you whether you wish to include all these names at the top of each message, or not. You are not able to send CC's in NetMail, EchoMail, or with File Attaches. Upload message Upload a prepared message. You will not be allowed to select this option if you already have selected to quote the original message. The uploaded file should be a standard text file. Not compressed, nor any other weird characters (those below ASCII 32). ANSI codes and graphics characters are allowed. When this feature is used from the console, it is called importing. You will then be asked for a pathname to load in as the message. In any case, the file containing the message is deleted after it is processed into an actual message. Processing includes truncating any additional lines beyond your set maximum number of lines allowed in messages. Normally that is 98 lines. When used at the console, if [Enter] alone is used, then the software looks for, and imports, all .PKT and .REP files in the d:\BBS\NODE.???\TEMPAREA directory. This is useful if you downloaded .PKT's or .REP's from someplace else, or the system was not able to unpack a .PKT at the time of its arrival due to lack of drive space. To minimize risk of deletion, you should shell to DOS and copy the files into the directory just before selecting to enter a message at a menu. Also, at the console, you may specify a specific .PKT to import. Of course, you can also specify a specific text file to simply import as message text. See also: SETTINGS File Attaches Select this if you wish to attach files to the message. When the message is saved, the software will ask that the author upload the files to be attached. Or, if at the console, the pathnames you wish to duplicate and attach to the message. The files are subtracted from the user's can-download bytes and daily time stats. This is done for all the files attached to the message, and regardless of whether one or more of the files were successful or not. That may sound strict, but it helps discourage use of the file attach system as an upload system (for interpersonal uploads). Files attaches are stored in the MSGSTUFF directory. Each message with files attached will have its own directory under the format: MessageNumber.Area Example: Private Mail (area 001) message number 5000 would be stored in \MSGSTUFF\5000.1. You, the sysop, may add or delete the files, or directory, without concern--there is no internal tracking done for the file attaches (the directory is either there and contains files, or it is not). This is useful for the future especially. Since users can upload voice mail (.MOD/.VOC/etc. files) as the message. If one of you out there can figure out how to turn on/off the modem carriers, then a command to record voice mail could be added (a similar command would be needed in the users communication program). Otherwise we will have to wait for video phones to hook up to computers. If you forget to select File Attaches, or just want to be lazy, then you can "just upload them" at the command line. This will cause the message to be saved, and for it to begin receiving the transferred files and attach them to the message. If the upload is aborted, or you want to add more later, you can do so from the reading messages command line. You cannot do File Attaches with Carbon Copies. Body Entering of text is straight forward. Quoted text shows up bracketed. Hitting backspace can go to the previous line. Cursor movement keys (up, down, left, right) are converted to backspaces (up, left) or spaces (right, down). There is no moving about the message with the cursor keys. With the exception of the cursor movement codes, ANSI codes are allowed in messages. Technical note: These cursor movement keys are "[A", "[B", "[C", and "[D". Now, these codes are a subset of the full ANSI set--so if a user wanted to upload a complex ANSI, theses codes might be part of it and screw it up. But the vast majority of times these keys get encountered are when the user tries to move around the screen to do editing. To use the same codes in an ANSI image as part of the message, one should use: "[1A", "[1B", "[1C", and "[1D". There is trouble, however, with ANSI lines that exceed 70 characters. So, while ANSI's are best in single-line form for menus, for messages they need to be in multi-line form. The Draw can handle both forms. To put ANSI codes into messages remotely, you must either do an ASCII file send of an ANSI file, or upload that part of the message as a message upload (then the cursor movement keys are allowed in the ANSI). ANSI's jumping all over the screen using either positional or cursor movements keys is simply not the way to do in-message ANSI's. The proper way is to design your ANSI to display a line of ANSI text/drawing, do a CR/LF, then display the next line of ANSI text/drawing, etc. until done. Like sending ASCII text, but with hidden ANSI codes. Quoting of text with ANSI characters can mess up the quote brackets' appearance--unless one follows the guidelines above. ANSI codes can be entered at the console using <Control><Left> to generate the ASCII 27, then type the rest of the ANSI string you want. Graphics characters (ASCII codes above 127) are also allowed in messages. This requires that the users communications program be able to send them. There is no way for a person at the console to generate these characters as yet. Exit to the command line by hitting enter twice. One may also type: /s, /es, /post, or /exit at the start of a line to immediately save and exit the entering message process. All the commands work alike. Hanging up saves the message (as "finish later"), but loses the line being worked on. If a user has toggled active grammar checking to ON, then each word is checked as they enter it, and a beep is sounded when that word is not found. User's should not have this option ON when doing an ASCII send of message text from their communication program's buffer or from a file at their end. This is because the beeping might screw everything up-- although I suspect it may be OK if both of you are using modems with MNP 4 or better. A //G may be typed at the start of any line to toggle active grammar checking from ON to OFF, and vice-versa. The "G" must be in upper case. See also: Colorizing Command Line Besides the commands below, auto-detect for ZModem and BiModem uploads is also done. Doing an upload in the middle of a message will not destroy the message, and it will be saved before starting the transfer. Users may set toggles to determine if the total number of words, lines, and/or characters should be shown. Editing by line number is much more difficult when the user has "no-numbers message entry" toggled to ON. % Save the message to a message file. Only the sysop may do this. The message body is then stored in a MESSAGE.xxx file. Which then can become part of other messages via the %%%xxx command. Abort Aborts the current message. No message is sent. Continue This lets you continue your message from the point where you entering left off. Delete lines Use this to delete a line or a block of lines from your message. Edit This option will search for an exactly matching string in the message, and replace it with another string you supply. This is the command to use for fixing up typos in the message. Finish later This will save the message as a special "I want to finish it later" message. What this means is that when you (the author) again read the message, you will have an option: "Continue message". Selecting this option will let you continue the message, edit it, etc. just as if you had never stopped. After saving, the author can still (or not) upload any file attaches if they wish. The message is saved--and actually sent. If the receiver logs on before you have finished (at a later time or date) then they will see it as a completed message. In theory, anyone could just use this instead of Save to save all their mail. Then later modify what they said in the message, and proclaim "that is what I said originally". The only defense for this is that the message numbers will be different, and the sysop could undelete the original (unfinished) message if he had to. This command is not available if the message has CC's. Grammar check This does a spell check on your message, and offers you the opportunity to correct the misspelled words. When a word is not found, and the user hits [Enter] when asked for the corrected spelling, that word is put into your WORDS.NEW file. This file will be utilized in the future when I add the ability to update the WORDSx.DAT files. While it is checking, hitting [Enter] or any of the valid entering messages command keys will bring you back to the command line. Insert lines Use this to insert text into your message. You will be asked which line number to insert before, then it will allow you continue using the normal message entry system. List This lists your message, including line numbers. Colorization codes are not acted upon, but simply displayed. While it is listing, hitting [Enter] or any of the valid entering messages command keys will bring you back to the command line. Preview This displays your message exactly as it will be seen by others when reading it. Colorization codes are acted upon. While it is displaying, hitting [Enter] or any of the valid entering messages command keys will bring you back to the command line. Save This compresses and saves the message. MESSAGE FILES Using an editor (or the "%" command) you, the sysop, or whoever you designate as the message-op (for an area) can send messages that include a special "load message file" command. This command, "%%%" when embedded within a message, will cause the software to search out a file and load it into the message when reading. Message files start with the name "MESSAGE." and contain a 3 letter extension ("xxx", so "MESSAGE.xxx"). It provides a method of sending lots of identical letters while using a minimum amount of drive space. Basically all these message files contain is text. You may create, or alter, these files with any standard text editor. Usually, though, you will just create the message and use the "%" command to save it to a file. With this method, the computer increments file extensions ("xxx") from the highest found (example: if you have MESSAGE.009 then MESSAGE.010 would be created). However, you may re-name these extensions to any three characters you like. Message files should not exceed 8,192 bytes in size. To do so is risky since it relies on string space. Inserting a message file into a message is simplicity: "%%%xxx" anywhere inserts the message ("xxx"). They do not need their own line. They can be in the middle of a "word": "You should%%%xxx.". They can be recursive--the file messages may contain "%%%" codes themselves--warning, the system does not protect you from looping, which will crash the system (looping: xxx contains reference to xxx, or xxx contains reference to yyy and yyy contains reference to xxx, etc.) The system only expands the "%%%" codes into messages if the message was sent by: the AI, the sysop, or the message-op for the area. Any other authors and the reader will see "%%%xxx". Similarly for message files that are not found, "%%%xxx" gets displayed. This allows you to use "%%%%%%%%%%%" without worrying, and users cannot find out your message file contents, nor use them in their own messages. Mass Mail uses these to send letters to users of a defined security level value. You also need to configure a message to be sent to new users (to introduce them to you, the BBS, and the interface). There is nothing stopping you from creating the messages on- the-fly and just using the "%%%" codes instead of re-typing large blocks of text. The "%" command lets you use the message entry system as a text editor. However, remember that messages are divided up by "paragraphs"--a paragraph is text followed by a CR/LF (an [Enter]). Remember, text is word wrapped. So if you edit the file, you will probably see lots of lines that extend past column 80. If you do choose to edit messages externally, I recommend only using CR/LF's where necessary, let the software do the word wrap (really, you just need to follow the same advice as Uploading/Importing message uses). You can use a standard text editor to edit or create the messages. I recommend you hit [Enter] only at the end of paragraphs (have long lines). This allows the software to do the word wrapping. Whereas having a CR/LF after each line will look weird if the message is quoted. Normally only the sysop and the AI may send messages with "%" codes. However, you may change a toggle to also allow all message-op's to also send messages with "%" message file codes. Message files are not limited by maximum number of lines. So you could use these to create really long messages. Although, if a user quotes the message, they will need to delete a lot of lines. %%%LOK is a special order. It will set the user's locked-out attribute, so that when they are done reading messages, they will be hung up on and locked out of the system. The "%%%LOK" command is ignored until the name logged in matches the TO: field of the message. This allows you, or anyone besides the person the message is to, to safely read the message. With any "%%%xxx" command, three stages are done: first we see if there is a MESSAGE.xxx file to display, if there is, then we show it. Second, if no MESSAGE.xxx file exists, we see if it is a special command, if it is, we do the command if possible. Lastly, we simply display the "%%%xxx" because we cannot do anything with it. A serious draw back with this: one can never remember which MESSAGE.xxx contains what. In a future version, I will change this to a "%%%pathname%%%" command. See also: SETTINGS, TOGGLES RAMBLINGS Ramblings are both message files and text files. They contain messages stored in text file format. Users append messages to the end of these files. Unlike regular message bases, however, these utilize the same HiFilePtr system as files do. After each logon, all formerly new ramble entries become old. Normal messages only become old when they, or a newer message in the same area, is read. Anyone can add to a ramble. Anyone above a defined SL may create a ramble. The creator may even restrict access to the ramble by a SL (SL's higher than the sysop's are not accepted). Only the creator of the ramble, or the sysop, can delete a ramble. Any ramble files containing new entries are highlighted. Ramble file information is stored in RAMBLING.DAT, and ramble message text is stored in RAMBLE.xxx (001 to 996). More than 996 will merely overwrite 001. While a user cannot upload a message in file form (like they can with the message system) they can do an ASCII send from their end (which they can also do with normal messages) to send up a prepared message. The ramblings menu has a statistics/title toggle option. The statistics are useful for finding new messages if you have not checked in on the rambles after a few calls. See also: SETTINGS FILE AREA You may list the contents of a file area using three formats: CONTENTS Standard, Point & Shoot, and paged. As you will see, each LISTING method has unique qualities. With the menu commands, you can have the software list all areas at once, provide a menu of all the areas, use your own menu of all or some areas, provide a menu of some areas. You may put some or all your file areas into a single file system, or bust them all up so they are grouped together or individually (known as topical menus: putting a related message area(s) and related file area(s) into the same menu). When showing description lines the software also does some checking to make sure things are OK. Checks include: file has an entry, file entry has the right file area, and the file entry's file size is the same as the file on the disk. The correction will be done automatically. The software maintains a global download batch. The P&S system interfaces this directly. The Paged method has commands to use it. There are also menu commands to use with it. See also: MENU SYSTEM Standard This method is invoked with "LstF" commands. When listing, [Enter], [Space], [Tab], "-", ".", and "!" are the valid keys. [Enter] stops the listing, [Space] or [Tab] will pause it. Hitting "-" will restart the listing, in the opposite alphabetical order (A-Z or Z-A, depending on what it was doing.) Or if you are listing the area by date uploaded, the reverse (oldest to newest or newest to oldest) will be done. Hitting "." will send you into the Point and Shoot File Selection and Information System. Hitting "!" will show who uploaded the various files. You can toggle this off for all but the file-op of the area. Also shown: date it was uploaded, date it was last downloaded, and number of times it has been downloaded. Files which are new to the user are highlighted white. After the date, or the size if date is excluded, there are five letters that may appear: f, g, i, p, and r. f appears if the file is free. g appears if the file is a group-specific-only file. i appears if the file is invisible. Only the file-op or sysop will see the file entry. p appears if the file requires a password to download. r appears if there is a review for the file. When a user tries to access a file area that his SL is too low for, the message "security level too low" will be shown instead of the contents of the area. This can be useful. Paged file system does not do this, and so the user never knows the file areas even exist. This allows you to show the user that file areas which he does not yet have access to do exist. Point & Shoot Unlike the Standard or Paged methods, the P&S method does not File Selection do any "correcting" of errors it finds. It does not list and files that are <incomplete> or invisible. It does not Information highlight new files. It does not display reviews. It does System not do automatic helpful exchanges for minute-credits or megabytes when the user tries to exceed one of the limits. It does, however, do things the other methods cannot. By providing an "interface screen" to the file area. From this method, a user may work on an archive, download files, and upload files. Auto-detect of Zmodem and BiModem uploads are checked. Because the screen size is limited, you will need to make sure no file area contains more than 96 file names. Movement is simple enough: either the arrow keys or number keys (keypad with "Num Lock" on). To move between file areas use "+" to move to the next file area, and "-" to move to the previous file area. Areas which have a Scan SL greater than the users, or have a PR restriction and the user has not passed PR, will not be shown to the user. To download files, you must first "tag" them. This is done by hitting the [Space], [Enter], or "5" keys. Tagged files can be untagged similarly. As you tag files, you will be given a summary of how much and how long your download session will be. Hit "/" to turn on the description line. This will give you the descriptions for each file as you move over the file names. Hit "/" again when you want to turn it off. Hit "?" to just give the description for a single file. This is much faster than "/". If "/" is active and you hit "?" than "/" will be turned off also. Hitting "." will switch you back to the standard type of contents listing. Use "d" to download the files you have tagged. Unlike the normal download menu option, this one will not do automatic exchanges to help you out, nor does it offer the option of auto-logoff. Use "u" to upload. Auto-detect of Zmodem and BiModem is also done. Unless you do not have access, or the current area is not set up as an upload area, all uploads will go to the current area. Otherwise an attempt will be made to put them in file area 001--if still no access, then you will be rebuffed. "v" will allow you View/Test/Extract from that archive. "q" will quit you out of the P&S system. See Standard above for some information on the description line. Paged File This method combines something from each of the above. It System lists the contents of a file area in 18 line pages, and allows an interface to many commands. There are many commands which use this method, but "PagF" is what they are all derived from. File areas to which the user does not have access are not shown. The area numbers (1..n) that the user will see is adjusted properly (if you have 4 areas and area 2 the user has to-low a security level value for, they still see 1, 2, 3, not 1, 3, 4). For each file area, a title line containing the area name and number is drawn, then 18 file descriptions. Then a command line. See Standard above for some information on the description line. The command line is like a file menu. The following are the command options: [Enter], ?, Quit, area number, Next area, Previous area, Upload, Add to DL batch, Batch contents, Show reviews, Download, Extended file info, Work on archive, Redraw, and Continuous. With the exception of "?" and "E", the rest of the commands work also while descriptions are being displayed. If you used a "PagF" call, and none of the others (such as "PagA"), then you can also type "." to go to the P&S system. This does not have "-" to reverse order while the descriptions are displaying like the Standard method does. [Enter] moves onto the next page if more files exist in the area, or moves onto the next area. "?" brings up a listing of the valid commands. You may just enter a file area number to jump to that area. Upload will let you upload to the current area. If the area does not allow uploading, it will try to let you upload to area 001 instead. Add to DL batch is used to add files you wish to download as the pages are displayed. Up to 100 entries may be stored in the batch. The software tallies up how many bytes the downloads would use, and will not let you add more files to the batch that exceed your daily limit. Batch contents shows you what is currently in the DL batch. It also offers you the opportunity to delete one or more of the entries. Show reviews will list the reviews (if any) for that file area. Only [Enter] and [Space] area allowed during the display of the reviews. Download allows you to download a file or the batch. If the batch is not empty, it will ask if you wish to download it. You can answer yes or no. If yes, it will send the batch (and then clear it--whether the download was aborted midway or not). If no, or the batch is empty, then it will ask you for a file name, and immediately start downloading that file. Extended file info toggles the showing of such things as who uploaded the file, when it was uploaded, the last time it was downloaded, and the number of times it was downloaded. It adds two extra lines to each description line, reducing the number of descriptions displayed to 6 per page. Work on archive will ask you for a file name to view/extract/test. Redraw redraws the last screen of descriptions. Continuous toggles ON/OFF the stopping after each screen full. If continuous is OFF, then it will still stop at the end of each file area. Auto-detect of Zmodem and BiModem uploads are checked. Support for the "post-listing requests display" toggle is done. It does not do automatic helpful exchanges for minute-credits or megabytes when the user tries to exceed one of the download limits. DOWNLOADING Users start out with 1 upload byte and 1 download byte--this is to protect from division by zero errors. At the downloading screen, callers are only able to enter file names until they reach the end of the line (4 or 5 file names). To do larger "batch" transfers they should use batch downloading. Wildcard's are not allowed. Since the wanted-for-download file names and paths are sent to a file, whatever protocol we use must be able to read in this file. The protocol must accept "@filename.ext" at the end of its command line (where filename.ext is our list of file names-currently it is named FNAMES.CTL). If the user selects auto-logoff, and at least one file was not sent, then auto-logoff is ignored and the user is returned to the system. That is, if auto-logoff is desired, then at least one file must have been successfully transferred before it will take effect. When downloading, either bidirectional or regular, the software will, through exchanges, try to meet their wishes. If they wish to download a file, and do not have enough time, but plenty of download bytes, and exchange is done for them, giving them enough time, with reduced bytes (if it is possible)--essentially saving the user the trouble of doing with Exchange. Exchanges are not done with regular "daily" minute allotments, but with minute-credits. Similarly for bidirection. Except the exchanges usually occur after the transfer. If the user exceeds their time allotment, then exchanges are done until they are OK again-- this can mean "borrowing" against the future (negative minute-credits). Should a user with negative minute credits (and few or no download bytes) try a bidirectional protocol again, he will have it limited to whatever his current download minutes are. Should his negative minute credits exceed his daily minutes allotment, then he will not be able to use the bidirectional protocols at all--indeed, he will not be able to download either, only upload. Abuse: It is possible to abuse the system by just logging on, using a bidirectional protocol for three hours of downloading, then logging off and repeating it with another name. For this reason I urge you to restrict bidirectional protocols to users of levels greater than your first ("new user") level. With "validated" user levels, no abuse is possible because ratios are always maintained--even if means that the user had to go into debt. Any imbalance "abuse" (such as doing three hours of downloading) will be handled the next time the user tries to download. The system is designed to be flexible, but a user who tries to abuse the flexibility will, sooner or later, run into a wall--which will require an upload. When a user downloads a free file (as denoted with an "f" in the file listings), the time and size are not counted against them, and do not appear in their stats at all (it is as if they never did it). It does, however, appear in the log files (callers and summary). This is true even if the download is aborted midway. When a download is not completed, bytes are not subtracted from the user's totals--they are only subtracted when downloads have been completed. While on the surface it may seem like abuse is possible (download 90% of the file and extract the remaining parts with "Work On Archives"), in reality it is too much work for a user to consider it worthwhile (they must use PKZIPFIX for ZIP's, they must take time to calculate where to stop, and if they screw up, they must repeat the whole process). I think only one user in two years of operation ever attempted this--I just manually added the bytes to his record, he never did it again. Uploading is much easier to do, and the user needs to have the stats to download the whole file in the first place to even start the transfer. Finally, the Exchange system allows users to maximize their file stats for need: time or bytes--which also has the effect to eliminate complex download abuse. Free downloads using the "FREE" menu commands do not take off time, or bytes. Potentially a user could just do a large free download all day to tie up your system. If this occurs, just make the free file download menu option with an SL higher than that of new users. Ultimately, if you find a user is trying to abuse your system--tying it up, calling and hanging up, etc. Calling the phone company and complaining about harassment is the best way--as the phone company has the calling logs and will be able to see who the caller really is, and prove the pattern of abuse. Password protected files are handled two ways. When the file name is typed at the downloads-file-name-entry-line they are allowed, when the user completes their entry, then the question regarding the password is asked, and they are only allowed to download it if successful. BiModem does not care about our internal password system, it has a system of its own with its own password file, you must put in these entries manually for BiModem to protect your password-protect files and your invisible files (since a user can find the name of an invisible file from the callers log--for long-term invisible's, short term invisible's have a low chance of being seen and are not worth the trouble). Normally, SL protection is done at the "get file name" part of the operation(s). We check DL SL for the file area the file is in, if not enough access, we pretend it does not exist. However, BiModem has no method to stop a user requesting any file from any of your "BiModem-accessible" defined areas (done with BIMODEM.DIR). Rather, what the software relies on to do this is for you to limit access to the BiModem protocol itself to only those users who can access all your file areas already. Downloading messages (with "MsgD") and downloading a Master List (using the internal Master List downloader) are also free downloads (no bytes/time taken off). The why is obvious: its faster than if the user did the same on-line, and therefore should be encouraged. UPLOADING When a user uploads a file, they are given minute-credits and byte-credits. Both of which are exchangeable for the other. Minute-credits allow more time for downloading, and byte- credits allow more bytes for downloading. │ You may postpone the giving of these credits until after you │ validate the file if you wish. You may only have one file on-line with the same filename.ext. If the user uploads a file with the same name as one that is already on-line, this is known as a duplicate. They do not receive credit for uploading duplicates, but they will be shown a note that they should leave you a message to get credit. Then, if the file is original, you should rename it, and manually give the user their UL bytes and minute- credits for the upload. Whether your BBS renames, overwrites, or rejects duplicates depends on your protocol and what protocol parameters you use. Normally, uploads will be given a "9" for L&D value, but Targeted uploads are given only a "2". If you disable the L&D system then this does not matter. Abuse: the only possible abuse involves logging on with a phony name, uploading some duplicate junk, downloading what they want, and then next time doing it with another name. This can be avoided by having a complex new user/access procedure, or just requiring uploads to be validated by you first. If a user relies on auto-detect ("just does it") for their upload (for instance, at an ANSI menu), then that upload will be put in file area 001 no matter what area they are in now. Exceptions to this: P&S and the paged method will first try to put it into the current area. If the user does not have upload access to area 001, after not being able to put the upload in the current area, the upload will not be allowed to take place. After a upload is done, there are a variety of post-upload processing that can be done. Including: insertion of BBS comments into .ZIP and .ARJ files, extraction to a file of .ZIP comments, extraction of .DIZ descriptions to your reviews files, and running of a virus checking program. These are registered features, however. See also: SETTINGS, TOGGLES, PATHNAMES Searching When a user selects a non-bidirectional protocol, they will be asked to enter a search string and a "search the off-line lists" will be done. It is the user's responsibility to make sure the software they wish to upload, is not in your lists. You may toggle this requirement (that they search before all uploads) ON/OFF. When searching the off-line lists, a text search is done--not a file name search. When a user enters a string to be searched for, several processing is done: all non-alphabetic characters are removed and only the resulting "first word" of the search string is used. If the user enters something common, like "ZIP" or "GIF" then they are refused--too many entries. The common words that are refused (when entered by themselves) are: ZIP LZH ARJ EXE COM GIF MAC PCX VERSION and PIC. You may modify these "no no" search strings, just change lines 0350 to 0359 in SHORT.TXT. If their search string is one or two characters in length, they are refused--too many entries. If their string contains no vowels, or a ".", then they are shown a note: "searching for a file name is not recommended". Indeed, the search field is only 10 characters in length to discourage searching for file names. But neither of these is discouraging enough, the biggest problem with this list searching is that users will constantly try file names-- rather than the main word of a program's title. They really should search for both. All characters after a "." are ignored. Someone should teach these users that there is not a law that says that what a file is named on one BBS is named on all the BBS's. If uploading (not when doing the menu command to search the lists), if they hit [Enter] before a search is completed, then it is assumed they do not want to upload, and are exited back to the menu. They need only one completed search in a series of searches to move on to the next step and upload the program. This prevents someone from searching part of the search file, but not all of it. Needed, because the file they wish to upload may be in that part of the list they did not see. If they know the file is not in your list, they can just enter a "scramble string" to do the fastest search (example: AJKLKAJKL). File Minute-credits will not be given until the user enters a Descriptions description for their upload. This may done later via the Review system. Using the file name as a description is ignored. Holding back of minute-credits is the punishment for users not using descriptions. This software is designed to reduce your workload. Users who have a SL greater than the lowest SL you have created, may use "/" or "\" as the first character of the description to make it a "sysop-only" file. This makes the file invisible--only the sysop or file-op will be able to see it. Once a valid description is given. The software will check to see if the file has a ".GIF" extension. If it does, then the dimensions of this GIF are entered into the description. GIF dimension entry is automatic for any file--it does not matter what file area the file is in. Files which have a ".GIF" extension but are not really GIFs are handled properly. If censoring is turned on, then only the file-op of a file area may enter uncensored descriptions. All ANSI codes are stripped out. The exception to this is when editing the file's record--then you (the sysop) can use ANSI codes. For color, the " }#word" system will provide it to everyone. One problem that seems to confound users is uploading multiple files (batch upload) that have different descriptions. Since if they enter the description first, all files are given that description. To make life easier on them, you might want to add the text "you will be given the chance to enter individual descriptions after the upload is completed." REMOVING FILES There are 3 ways to remove files: deleting them by hand, deleting them with the "oust files" routines, and deleting them by using L&D delete. Deleting by hand simply involves using DOS's DEL command. It is what you probably do to delete files on your hard disk or floppies that you no longer want. When doing this to files in your downloads areas, you should do it before starting up the BBS. If you do delete a file while the BBS is running (by shelling to DOS or through a door) then the BBS will not know that you deleted it--some routines will still allow that file name to be typed, displaying a "file not found", and probably confusing your users. The second method, "ousting files" via the two sysop menu commands: Oust Files and Oust Files/Penalty, or by setting the "1" attribute with File Maintenance, will delete the first occurrence of a file. If you have two files with the same name, the first file area found to contain the file will lose it--usually the uploads area is the first area, depending upon how you configured your BBS. The difference between Oust Files and Oust Files/Penalty is that Oust Files repeatedly loops asking you for files to simply delete. Oust Files/Penalty asks you for a file name, finds out who uploaded it, then asks you for a reason why you are deleting it (corrupt, or a duplicate, whatever), a message containing your reason and other information is sent by the AI to the user, and finally the file itself is deleted. The text of the AI's message can be found, and edited, in LINES.TXT. The third method is using the Life & Death system. When a file's L&D count is at zero ("?"), and a variety of conditions are met (see L&D menu command) then a user may choose to "reduce" the L&D value further--delete it. With any of these methods, the deleted file name, size, and description, are written out to the log file and the ALSO_GOT.LST file. If you use DOS's DEL command, then the software will recognize the files as missing and consider them deleted. If you should accidentally delete a file, and then put it back into any download directory, then the software will automatically undelete the file entry for you. If you should only change the extension of a file, the software will properly handle that as well. When deleting files, the file is deleted off the hard disk, then it is deleted out of memory, and finally any reviews about that file are removed from the reviews files. None of the above are as complex as they sound. I just described in detail what happens. Everything is automatic. When you use DEL you just type a file name. When you use Oust Files, you just type a file name. When you use Oust Files/Penalty, you just type a file name and a reason (I like to keep mine to one word). With L&D delete you just type the file name and a Yes/No confirmation. MISC. When you get a percentage progress report: ▓▓▓█████ (30%) Do not worry if it ends at less than 100%, it may end at 95% if the numbers are "just so" and it may end up much lower if there are not that many things to do. If one gets "No messages found." when reading logon mail-- after having been promised mail ("You have the following..."), then this is not a problem. It is possible the sender of the message sent it, but deleted it later (before you called) or the system deleted it because it was too old (if circular buffer is in effect) and you had not called in a long while. But it usually occurs after you have already read your mail, and then went on to somehow crash the BBS or used the <alt>x command. The BBS copies all files from your RAMTEXT directory to your RAM drive when it is run--unless they are the same. The RESULTS file will still contain my BBS's voting totals and system statistics. Just run "update system stats" from the sysop menu to eliminate it all. The BiModem configuration files were included to aid in setup of BiModem. You still need to go through and make sure the path's and modem type are correct with BICONFIG.COM. I AM LOST!?! If you have gotten to this point, and you have not tried the software yet, you are probably really confused. I have given you the architect's designs of the building, but all you want is the front door, elevator, and location of an office. Toss out BBS2.ARJ--that is the last thing you need now. Run the program, see what happens, how it works, etc. However, be aware that a lot does not show up until it is in full operation. In this initial configuration, it is a scaffolding--it may even appear simplistic. Do not think about what it is, or what it can be. Take change a little at a time. Look over the stuff you do not know only when you want, or need, to know it. This is not a "BBS construction set"--although it can be. You do not need to be a programmer--although you can be. YOU decide how "deep" to get into this software. Laugh off all the confusing stuff--it can be ignored, but it will be there when you need it. CUSTOMIZING You probably have an urge to jump in and start changing the 101 menu ANSI's and the menu commands. Do not. Your first step should be to customize the internal structures of the BBS. This means using the sysop menu commands: Change Settings, Alter Pathnames, Toggles, and other Configuration menu commands. Indeed, Toggles should be your first stop--as it is the easiest. Then Change Settings. These modify the limits of your BBS. Believe me, I know it is complex, I must urge you to take very small steps in your change-over of the software. Do not read more into what you see, follow the examples, if I do not say it cannot work--then you can probably do it. See also: SECURITY LEVELS, FILE AREAS, MESSAGE AREAS, CONVERSION TOGGLES From the sysop menu, or <alt>t from Waiting-for-caller, brings up the following menu: ┌───────────────────────────────────────────────────────────┐ │A. User related toggles. D. AI's brain. │ │B. System related toggles. E. System related toggles 2. │ │C. Message related toggles. │ │ │ │Which would you like to alter ([Enter] to quit): │ └───────────────────────────────────────────────────────────┘ Each option breaks down into a screen of toggles: ┌─Toggles────────────────────────────────────────────────────────On─────Off────┐ │ A. Users can do Life & Death delete. ▄ │ │ B. Allow new users. ▄ │ │ C. Ask for second name (SysopNote) at first logon. ▄ │ │ C. Use the file areas ANSI menu. ▄ │ │ D. Sysop available for chat. ▄ │ │ E. Trap all chat sessions to file. ▄ │ │ F. Users see UserNote at login. ▄ │ │ G. Console always shows full callers log. ▄ │ │ H. Hacker protect sysops name. ▄ │ │ I. Censor superlatives from descriptions. ▄ │ │ J. Censor 'non-words' from messages and descriptions. ▄ │ │ K. Hang up after phone verifications. ▄ │ │ L. Phone verification allows long-distance numbers. ▄ │ │ M. All users can use "!" when listing file areas. ▄ │ │ N. Must search lists before they can upload. ▄ │ │ O. Uploads must be validated before giving credit. ▄ │ └──────────────────────────────────────────────────────────────────────────────┘ Users can do Life & Death delete. When ON, users may use L&D to actually delete a file. Allow new users. When ON, your BBS will allow new users. Turn this OFF if you do not wish new users. If OFF, you will need to add user accounts by hand (which involves turning this ON, and logging in locally under the new name). Ask for second name (SysopNote) at first logon. When ON, first time callers will be asked for a real name, in addition to the normal name question. This name will be stored in their SysopNote field. Sysop available for chat. When ON, users will be able to try and chat. Trap all chat sessions to file. When ON, any chat you do will be trapped to the chat file. Users see UserNote at login. With the "Logon Note" option, a user may leave a note to themselves that appears when they login. However, you may re-word this "Logon Note" to use it to get any information from the user, which is then kept in their UserNote field. Information you might want to get: Self-praise, street address, zip, system type, occupation, where they heard of the board from, amateur radio call sign, etc. By turning this OFF, you can use it as a second sysop note field. Console always shows full callers log. When On, when a user lists the log, you will be able to see the entries that the user cannot at the console-- otherwise you will just see what they see. It shows you the callers log as you would see if you were logged on. Either way the user does not see the "red" entries. Hacker protect sysops name. When ON, this provides complete protection against users hacking at your account. Censor superlatives from descriptions. When ON, words like "excellent" and "great" will not be allowed in the file descriptions. Censor 'non-words' from messages and descriptions. When ON, users will not be able to use words like "alot" and "l8tr". All users can use "!" when listing file areas. When ON, any user may use "!" while listing the file area contents to get the secondary information line (who uploaded, etc.)--otherwise only the sysop and file-op can. Must search lists before they can upload. When ON, users are required to search the file lists (specified in the Search Files database) before they will be allowed to upload. Hang up after phone verifications. When ON, users must call the BBS back if they want to continue their session after passing call-back/phone verification. This is only really needed for long distance calls, or when you are billed for usage. Phone verification allows long-distance numbers. When ON, users can enter a long-distance number to be called for call-back/phone verification. Uploads must be validated before giving credit. When ON, a user must wait for the sysop to validate their upload before they will see any download bytes or minutes credit. When OFF, they are given their download bytes and minutes credit immediately after the upload. ┌─Toggles────────────────────────────────────────────────────────On─────Off────┐ │ A. Use BIOS (fast) screen writes. ▄ │ │ B. Keep the screen blank. ▄ │ │ C. You are the next user on. ▄ │ │ E. Show quotes when log off. ▄ │ │ H. Trap all sessions to file. ▄ │ │ I. Expand ANSI's to session trap file. ▄ │ │ J. Port has locked baud rate. [door programs use] ▄ │ │ K. Console commands are accepted. ▄ │ │ M. Ask for caller's location at first logon. ▄ │ │ N. Allow single-word names (usually 'handles'). ▄ │ │ O. The defined port is a null modem. ▄ │ └──────────────────────────────────────────────────────────────────────────────┘ Use BIOS (fast) screen writes. When ON, the software will use a combination of BIOS and direct screen writing to speed up display speeds. It doubles the display speed. However, it is limited where it can be used. It cannot be used in graphic environments, multi-window environments (such as DesqView) and perhaps under other circumstances. So try it, if it works, great, if not, you can use /BIOS to toggle it OFF when restarting. For CGA monitors, there is still some slight snow when the screen clears--but the speed advantage makes it worth it. Keep the screen blank. This is the menu version of the F6 command key. When on, you will not see anything--the screen will be kept blank. You are the next user on. This is the menu version of the F5 command key. When ON, the system will immediately go into console logon mode after the current caller (if you are at this menu, it means after you logoff). Show quotes when log off. When ON, the user is given a quote before hanging up. Trap all sessions to file. When ON, everything sent to and received from the modem is trapped to a file exactly as it appears--note, this can add up VERY quickly. Because trapping of the session to disk slows things down tremendously, I recommend you trap to a RAM disk file if you have the memory. Expand ANSI's to session trap file. When trapping a session to a file, if this is ON, then instead of storing the ANSI files it sends out, it stores them in the form: ≡≡E:\FILENAME.ANS≡≡. Considering that each menu ANSI is like 1k--this drive space savings is significant. Port has locked baud rate. [door programs use] You lock your baud rate in the CONFIG.SYS fossil command line. Setting this toggle, however, tells some door programs that you have a locked port. There is nothing in the program itself that uses this toggle. Console commands are accepted. When ON, commands such as <alt>t and the rest are accepted from the console at the waiting-for-caller screen and when a user is on. Otherwise the only command allowed is <F9> (logon locally) from the waiting-for-caller screen. Ask for caller's location at first logon. Besides name and verification, location is the only other question a new user is asked. You can turn it OFF if you do not want to ask it then. Allow single-word names (usually 'handles'). When ON, a user may enter a single word and it will be accepted as a valid name. When OFF, entering a single word is assumed to be only a first name, and they will be prompted to enter a last name. The defined port is a null modem. If the comm port is a null modem, then turn this ON. If it is a real modem, or the console, then turn this OFF. Normally the toggle is not set here, but in a "port is null modem [y/n]" question after you change the comm port with "Change Settings". ┌─Toggles────────────────────────────────────────────────────────On─────Off────┐ │ D. Grammar Check is installed. ▄ │ │ E. Message-op's can do "%" message files. ▄ │ │ F. AI sends a message when penalize. ▄ │ └──────────────────────────────────────────────────────────────────────────────┘ Grammar Check is installed. When ON, the system lets users do a Grammar Check of their messages. When OFF, it is assumed you deleted the 500k of WORDS files so Grammar Check is not allowed. Note, if you do not want Grammar Check, you will need to remove "}2G}7rammar Check," from LINES.TXT for the entering messages command line. Message-op's can do "%" message files. When ON, message-op's will be able to use "%" to create message files which can be accessed via "%%%" commands. Normally, only the sysop can do this. AI sends a message when penalize. When On, the AI Oust with Penalty option will include the file name, file size, and a note about what happened in a message to the user. ┌─Toggles────────────────────────────────────────────────────────On─────Off────┐ │ A. Name detection/completion. ▄ │ │ B. Bytes to/from Minute-Credits when-needed conversion. ▄ │ │ C. Filename detection/completion. ▄ │ │ D. Borrowing from future Minute-Credits. ▄ │ │ E. Bytes to Minute-Credits when-needed conversion. ▄ │ └──────────────────────────────────────────────────────────────────────────────┘ Name detection/completion. When ON, the software will automatically complete names as they are entered. When OFF, the software will still only let users enter letters corresponding to active users, but it will not complete the name for them. If a partial name is entered, then [Enter] is pressed, sometimes the software will simply use the full name as if auto-detect was ON. Either way, login name handling is only a little bit effected, since it has/had to be much more flexible to start with. Bytes to/from Minute-Credits when-needed conversion. When downloading, the software will attempt to do exchanges for can-download-bytes->minute-credits or minute-credits->can-download-bytes. This is a convenience rather than the user doing the exchanges themselves with the Exchange routine. When OFF, no can-download-bytes will automatically be converted to minute-credits. This is only used when selecting files to download. Filename detection/completion. When ON, the software will automatically complete file names as they are entered. When OFF, it will not complete the file names, but does still restrict allowable letters to files that are active. Borrowing from future Minute-Credits. When a user exceeds their time while uploading or downloading, the software will take that amount from "future" uploads. Turning this OFF means users do not lose from future uploads when they exceed their numbers (such as when in BiModem). Bytes to Minute-Credits when-needed conversion. When downloading, the software will attempt to do exchanges for can-download-bytes->minute-credits or minute-credits->can-download-bytes. This is a convenience rather than the user doing the exchanges themselves with the Exchange routine. When OFF, no minute-credits will automatically be converted to can-download-bytes. Turning off the AI toggles really does make the software much more simplistic. These actions above were designed to continue the work the users would otherwise have to do on their own. │ ┌─Toggles────────────────────────────────────────────────────────On─────Off────┐ │ │ A. Insert text from comment file into uploads. ▄ │ │ │ B. Save archive comments from uploads to a file. ▄ │ │ │ C. Last few callers: show current caller. ▄ │ │ │ D. Last few callers: show Console logons. ▄ │ │ │ E. Last few callers: show only for that node. ▄ │ │ │ F. Extract FILE_ID.DIZ into Reviews from uploads. ▄ │ │ └──────────────────────────────────────────────────────────────────────────────┘ │ │ Insert text from comment file into uploads. │ When ON, the software automatically insert your header │ comment file(s) into .ZIP and .ARJ uploads. │ │ Save archive comments from uploads to a file. │ When ON, the software will extract any .ZIP header │ comments into a text file (so you can view them). │ │ Last few callers: show current caller. │ When ON, the "last few callers" screen will show the │ current caller as the first entry. │ │ Last few callers: show Console logons. │ When ON, the "last few callers" screen will include all │ the "Console" logons. Turn OFF to hide your logons from │ the "last few callers" display. │ │ Last few callers: show only for that node. │ When ON, only those who have called the current node │ will be shown. Turn OFF to list the "last few callers" │ to the BBS--not just one node. │ │ Extract FILE_ID.DIZ into Reviews from uploads. │ When ON, FILE_ID.DIZ description files will be extracted │ from uploaded files and their text will be added to the │ file reviews file for that upload area. SETTINGS Selecting "Change Settings" from the sysop menu, or <alt>a from the waiting-for-caller screen brings up the following menu: Changes take effect/are saved when you exit the main settings menu. ┌──────────────────────────────────────────────────────────────────────────┐ │Those entries with '(restart)' next to them will take effect the next time│ │the BBS is restarted. │ │ │ │A. File areas C. Security levels E. Other 1 │ │B. Message areas D. Space limits F. Other 2 │ │ │ │Which would you like to do ([Enter] to quit): │ └──────────────────────────────────────────────────────────────────────────┘ Which in turn break down to the following screens: ┌──────────────────────────────────────────────────────────────────────────┐ │A. Maximum number of files to keep active at one time: 512 │ │B. Maximum number of files to keep active in any dir (restart): 100 │ │C. Maximum number of FILE_ID.DIZ -> Reviews lines to import: 10 │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Maximum number of files to keep active at one time Maximum number of active download file names you will think you will have on-line at one time. Maximum number of files to keep active in any dir (restart) Maximum number of active download file names you will think you will have on-line in any single download directory at one time. Note however, that this value is also used elsewhere-- and if you run a really large BBS, you will probably need to increase this. Maximum number of FILE_ID.DIZ -> Reviews lines to import If you automatically import FILE_ID.DIZ descriptions into your reviews files, this will limit the number of lines imported. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Maximum number of messages to keep active at one time (restart): 1,024│ │B. Maximum lines allowed in a message: 99 │ │C. Maximum characters per message line when reading: 79 │ │D. The width of news text: 70 │ │E. New user MESSAGE.xxx: 001 │ │F. Message area for mass mailings: 1 │ │G. Maximum number of rambles a user may create per call: 5 │ │H. Maximum number of messages a user may post per call: 10 │ │I. MESSAGE.xxx to inform user he's undergoing peer-review: 003 │ │J. MESSAGE.xxx to inform user he's passed peer-review: 004 │ │K. MESSAGE.xxx to inform user he's failed peer-review: 005 │ │L. Your FidoNet node address is: 0:0/0 │ │M. Your FidoNet HUB's node address is: 0:0/0 │ │N. Maximum number of messages to allow to download at a time: 500 │ │O. Number of lines for each Mini-Note: 5 │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Maximum number of messages to keep active at one time (restart) Total number of messages in all areas to keep active at one time. As with all these "total active" fields, you may have thousands of inactive entries--they do not matter, only the active ones do. Maximum lines allowed in a message Maximum number of lines to allow in a message. 99 is good, as at most it uses 8k of string space. Internally though, this becomes 16k, 25-30k is the maximum--so if you want more lines,play around, if the system runs out of string space, you will know when you have made it too large (probably 180 is too big). Really, only maximum - 1 lines in a message are allowed. The software will display line numbers "100"+ in two digits: 00 to 99 (98, 99, 00, 01, etc.) It looks funny- -but like I say, going beyond the 99 limit is risky as it simply has not been tested. Maximum characters per message line when reading When reading (and perhaps entering) messages, it is set to a width of 79 characters now. But your BBS personality may require a shorter or longer width. Example, if all your users use 132 column modes, then a width of 130 would be OK. The width of news text This is the width of centered NEWS. Example: 70 provides a 5 character margin on each side of the news text. New user MESSAGE.xxx New users are sent a message from the AI. Currently, they are sent MESSAGE.001. However, for example, if you were to change this to "NEW", then users would be sent MESSAGE.NEW. Set this to "000" to not send a new user message. Message base for mass mailings This is the message base number to use for mass mailing messages. A 1 corresponds to Private Mail. Maximum number of rambles a user may create per call Just what it says. Maximum number of messages a user may post per call Just what it says. MESSAGE.xxx to inform user he's undergoing peer-review When you use the "?" key to send a user onto Peer Review, they will be sent this message. Use "000" to not send a message. MESSAGE.xxx to inform user he's passed peer-review When a user has passed Peer Review, they are sent this message. Use "000" to not send a message. MESSAGE.xxx to inform user he's failed peer-review When a user has failed Peer Review, they are sent this message. Use "000" to not send a message. Your FidoNet node address This should be FidoNet node address if you have one. Your FidoNet HUB's node address This should be HUB's node address. Usually this will mean your FidoNet HUB, but it should be whatever HUB address you use. If you do not use net mail, you do not need this. Maximum number of messages to allow to download at a time There is an internal maximum of 2000 messages that can be downloaded at one time. But you may set this still lower depending on your own preferences. Number of lines for each Mini-Note Mini-Notes will appear in .09. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Minimum Security Level value to do L&D delete: 20 │ │B. Minimum SL value needed to make Targeted requests: 20 │ │C. A Co-sysop is SL value: 99 │ │D. Minimum SL value needed to vote: 10 │ │E. Minimum SL value needed to add/create a ramble: 10 │ │F. Minimum SL value to include in Worst Statistics screens: 5 │ │G. Minimum SL value to do bidirectional file transfers: 10 │ │H. Post-Peer Review SL value to give to confirmed user: 5 │ │I. Minimum SL value needed to do peer-reviewing: 20 │ │J. Maximum SL value allowed to do peer-reviewing: 20 │ │K. Minimum SL value needed to do sysop-only uploads: 10 │ │L. SL value to give after successful call-back: 5 │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Minimum Security Level value to do L&D delete One uses an SL menu gate for access to L&D. But this contains the minimum SL that is required to do a file delete with the L&D system. There is also a Toggle which must be set to allow L&D delete. Minimum SL value needed to make Targeted requests The SL value needed before users can make requests of each other and Target Upload files to each other. A Co-sysop is SL value The SL value you have decided should be for co-sysops of your BBS. Used only in some door programs. Minimum SL value needed to vote The SL value a user must have to vote. While you may provide access to the voting system for users of a SL with the menu system--their votes will not matter unless they have a high enough SL. Minimum SL value needed to add/create a ramble The SL value a user must have in order to start a ramble file. Minimum SL value to include in Worst Statistics screens The SL value a user must have to get on to the worst statistics screens. In general, your lowest level users will always have the worst statistics. This, and/or a minimum number of logons, can eliminate many of the "deadbeats" and show who is worst among the "good" users. Minimum SL value to do bidirectional file transfers The SL value a user must have in order to do bidirectional (eg. BiModem) transfers. Post-Peer Review SL value to give to confirmed user After a user passes Peer Review, they are given this SL value. Minimum SL value needed to do peer-reviewing The minimum SL value a user needs to do a Peer Review voting on another user. Maximum SL value allowed to do peer-reviewing The maximum SL value a user needs to do a Peer Review voting on another user. Useful if you do not want fellow sysops to vote on users. Minimum SL value needed to do sysop-only uploads The minimum SL value a user must have in order to have a description starting with a "/" or "\" be accepted to mean that the upload is to be for the sysop only, and invisible to all users but the sysop. SL value to give after successful call-back This is the security level value to give a user after they successfully pass a call-back verification. If set to zero, then the user's SL value is not changed from whatever they have. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Minimum drive space needed to do new stuff (Requests/etc.): 8,192 │ │B. Emergency buffer size (number of 4096 increments): 2 │ │C. Minimum space before AI starts asking for help: 1,000,000 │ │D. Minimum space to allow uploads: 100,000 │ │E. Minimum space before allow L&D deletes: 1,000,000 │ │F. Minimum space to allow Targeted upload: 2,000,000 │ │G. Minimum space at which to stop 'be sure' message: 3,000,000 │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Minimum drive space needed to do new stuff (Requests/etc.) At various times, your drive will fill up. When it reaches the value specified, the software will not let any "adding" features be done (adding to reviews, requests, etc.) to avoid the risk of filling the drive completely and crashing the system. When it goes below this amount, no logging is done--of transfers or anything else--and no messages are allowed to be posted. However, if there is enough room for a DSZLOG entry by DSZ or BiModem, then any user downloads will still be handled properly. Emergency buffer size (number of 4096 increments) Emergency drive space (2 here = 8192 bytes). Typically, an upload session can use every last byte on your drive- -before the protocol aborts due to lack of space. This emergency space is stored in a file. When an upload is done, if the drive is full, then this file is deleted, freeing up space. This space is needed to do proper logging of the file transfer and other log entries. The amount of emergency drive space should be greater then amount of minimum drive space you noted above.--to allow further logging. Minimum space before AI starts asking for help If you have L&D delete toggled to on, then when the drive space falls below this value, the next caller with high enough access will be asked by the AI to use their L&D delete ability to make space. This is done at logon, when they are given a list of potential candidates for deletion. This occurs with the menu command "Asst" is in your MENUTEXT.DAT "logon loop". The command should be set to the same SL value used above to allow L&D delete. Minimum space to allow uploads When the drive space falls below this amount, users are not allowed to upload. Minimum space before allow L&D deletes When the drive space falls below this amount, then L&D delete of a file is allowed, otherwise it is not. Minimum space to allow Targeted upload When the drive space falls below this amount, then Targeted Upload is not allowed. Minimum space at which to stop 'be sure' message When uploading, after the available drive space, if there is less than this amount, then a "be sure it is enough" is also displayed. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Number of days to maintain the summary log at: 30 │ │B. Maximum number of users to keep active at one time: 1,024 │ │C. Minimum verification length for lowest level users: 0 │ │D. Minimum verification length for validated users: 5 │ │E. Number of minutes of connection before reset: 1 │ │F. Number of minutes of no connection before reset: 5 │ │G. Bytes exchange rate: 1,000,000 │ │H. Minutes exchange rate: 10 │ │I. Penalty (use 200 for 2.00, etc.) multiplier: 200 │ │J. Maximum verification attempts before hangup: 2 │ │K. Maximum name attempts before hangup: 3 │ │L. Minutes of inactivity before a user is timed-out: 4 │ │M. Minutes of inactivity at logo before disconnect: 1 │ │N. The size of the stats rankings screen is: 18 │ │O. Minimum number of logons to include in Worst Statistics: 3 │ │P. Minimum baud rate to avoid BiModem-only day restriction: 0 │ │Q. Pass/fail votes (difference) a Peer Reviewee needs: 5 │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Number of days to maintain the summary log at This will be implemented in .09. Maximum number of users to keep active at one time Total number of active users to maintain at one time. When this number is reached, new users are told to try again next week. Their names are not stored and they never get farther than the login screen. Minimum verification length for lowest level users Minimum verification length required for your lowest tier users. Using a minimum of zero can cause some confusion with new users. If they stumble into a person's name with a zero length password, all they need do is hit [Enter] to access the account. But, one can argue, "anyone who has such an easy password deserves...". Minimum verification length for validated users Minimum verification length for everyone above your lowest tier. Number of minutes of connection before reset After a modem connection is made, how long should it wait (in minutes) for a response/start of session. Number of minutes of no connection before reset After how many minutes of inactivity should we reset the modem. This provides us with security of knowledge that no matter what kind of random actions occur, the system is being reset every x minutes. It is sort of a security blanket, you can probably give this a high number and forget it exists. Bytes exchange rate Exchange rate between minute-credits and bytes. This contains how many bytes the exchange is worth. Minutes exchange rate Exchange rate between minute-credits and bytes. This contains how many minute-credits the exchange is worth. Penalty (use 200 for 2.00, etc.) multiplier When you penalize a user via the Oust Files/Penalty option, this multiplier determines how much to take off. 200 for double bytes off (upload bytes * 2), etc. Maximum verification attempts before hangup Number of wrong verifications allowed before hanging up on them. Maximum name attempts before hangup Number of bad name attempts allowed before hanging up on them. Minutes of inactivity before a user is timed-out During their session, number of minutes of inactivity-- when they do not type anything--before we hang them up. Minutes of inactivity at logo before disconnect Before a user actually logs in (during the logo, shuttle, etc.) this determines how long they are given before hanging up due to inactivity. This should be short, since users with auto-dialers tend to forget about them and are not around when a user finally hangs up--hanging up your system yet again with their unattended login. This delay is also in effect when the system expects a "quickie" answer (such as Y/N) or when entering a user's name (such as at login). The size of the stats rankings screen is The statistical rankings screen size. 18 fits perfectly on a screen, but you can extend this and the rankings will scroll down when viewed. After changing this, you must run Update Stats or you will just get nonsense when Stats Display is run. Minimum number of logons to include in Worst Statistics The minimum number of logons a user must have in order to be considered for the worst stats screens. Helps to eliminate "non-participatory and soon to be deleted" users from clogging up the worst stats screens. Minimum baud rate to avoid BiModem-only day restriction The minimum baud rate a user needs to have called at to not be required to follow the BiModem day rules ("if today is BiModem-only day, no other protocols are allowed"). A user with a baud greater than or equal to this will not be affected by BiModem day. Actually, the calculation is: if CPS rate * 10 > Baud then ignore BiModem day. If it does not work properly (for instance 9600 baud is 960--but you may use a CPS rate of 920-- then just decrease this setting (baud here) until its in line (9200 would do). This setting is just a number, not a real baud rate. That still sounds confusing. Easier: if you want to restrict all callers below 9600 to use BiModem every- other-day, then set this value to 8000. The CPS rate it uses in its calculations are derived from your CONNECT strings database. Which is why I am being so fuzzy here--one sysop may say 890 CPS at 9600 baud, another may say 1100 CPS. Setting this to 0 turns off BiModem-only days. Pass/fail votes (difference) a Peer Reviewee needs The difference which must be obtained for a user undergoing Peer Review to either pass or fail the process. The difference is simply the number of passed votes greater than the number of failed votes, or vice-versa. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Sysop name: JOHN ROHNER │ │B. Your BBS's phone number is: 414-643-1576 │ │C. Log leading character(s) for sysop-only info: |= │ │D. Comm port to use (1 = COM1:, etc.): 1 │ │E. The current node is: 1 │ │F. HiFilePtr value: 1,854 │ │G. Show free space on which drives at waiting-for-caller: CDE │ │H. Your registration key 1 is: │ │I. Your registration key 2 is: │ │J. Your registration key 3 is: │ │K. First command to execute when a user calls: STRT │ │L. Total number of calls to the BBS so far: 1,221 │ │M. Maximum baud rate of your modem: 19,200 │ │N. The size of the last callers screen is: 10 │ │O. Level/type of logging to do attributes are: 1234567890ABCDEF │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Sysop name The sysop's name, used for most things when the sysop's name is needed. Your BBS's phone number This should be your BBS's phone number. You must include the area code. Currently it is used two ways: to determine when long distance numbers are long distance or not (for call back verification), and when determining if a net address's phone number is a long distance call or not. Log leading character(s) for sysop-only info The character(s) to use in the callers log file to designate sysop-only-visible entries. You may specify up to 5 characters. Trailing spaces are ignored, leading spaces are kept. Leaving this blank will make all entries visible to everyone. Comm port to use (1 = COM1:, etc.) Use 0 for local-only operation. Otherwise it is the port your modem is connected to. It asks you if this port is a null modem, answer: No. After changing this, the system will use that comm port value when you hang up. If you accidentally entered the wrong value, and you have no way of accessing that port, and the system "freezes" while trying to access it, you should just replace SETTINGS.001 with an older version (backed up or from the BBS.ZIP archive.) The current node For whenever multi-nodal operation is installed. The current SETTINGS.xxx file is not changed. A new SETTINGS.xxx (where xxx is the new node value, eg. 002) is created, and any other settings changes will also be put here. It then "switches" internally to the new node--using pathnames with the new node value instead of the old (so they must exist before you change this value). HiFilePtr value HiFilePtr's are line message numbers. Every time a new file is put, or a new review, ramble, or request, is put up, this number in incremented, and that new item is given this value. It is not really meant to be be messed up by you, but I put this in just in case. Each user has a HiFilePtr field in their records, which is then compared against the current values of each item, to find out what is new. Show free space on which drives at waiting-for-caller When at the Waiting-for-caller screen, it will display the amount of drive space available on whatever drives you give (up to five). Your node address This is where your FidoNet node address is put. You cannot just create your own, you must get one from the network manager in your area. To find out who that is, ask sysops in your area code who are getting netmail. You do not need a node address to contact other JDR_BBS systems. Your HUB's node address This is the node address of your local HUB. It is used when you specify "HUB" in the routing files. You do not need a hub to send mail to other BBS's, but for long distance calls, it is usually cheaper to use one. Your registration key 1 Registration KEY 1 that you get when you register. These keys are used to decrypt encrypted messages and unlock your registered commands. Your registration key 2 Registration KEY 2 that you get when you register. These keys are used to decrypt encrypted messages and unlock your registered commands. Your registration key 3 Registration KEY 3 that you get when you register. These keys are used to decrypt encrypted messages and unlock your registered commands. First command to execute when a user calls This is your first menu command to execute. Usually it contains all the commands you want to do while the user is logging in. Total number of calls to the BBS so far This is the storage for the total number of calls to your BBS ever. It is increased by one with each logon. Maximum baud rate of your modem This is the speed you wish the software to communicate with your modem at. If your system does not respond when sending commands such as the modem initialization command, then you should make sure this is correct. The size of the last callers screen is This is the number of users you wish to display for the "show last few callers" screen (at login). Level/type of logging to do attributes are This is also referred to as "LoggingAmount". It allows you to turn ON/OFF most all types of logging. Below is what each attribute does: 1 Record each user, or non-user, who calls. 2 Record each time a user generates an unwanted user name. 3 Record each time the BBS is restarted. 4 Record when a wrong password is entered. 5 Record when and which events are executed. 6 Record each time a user changes their password. 7 Record the phone number which with a user passed, or failed, call-back. Record when a user passes, or fails, peer review. 8 Record each chat attempt's reason. 9 Record when a user has been penalized, and what the file was. 0 Record when you have deleted a user. A Record file transfers (copied straight from protocol log). B Record net mail stuff. C Record when a file is removed/deleted/disappeared. D Record when do a minor fix to a file or message entry (adjustments). E Record what was purged in purging operations. F Do internal error checking after each command. "F" does internal checks after each command to check for internal (programming) errors such as: handle mismatches, low string space, string space corruption, a left-over TEMPFILE, etc. Those with "(restart)" in them requires that the BBS be exited and restarted again before they will take effect. These represent arrays--that use memory--so bigger is not always better. PATHNAMES Selecting "Alter Pathnames" from the sysop menu brings up the following menu: Be sure the pathnames you give are correct--as the software does not complain when it cannot find a pathname. And the errors you get may be subtle. When using "LoggingAmount" (see SETTINGS) with the "F" attribute (watchful diagnostics) ON, if you get "handle mismatch" in the ERRORS.LOG file, then it is usually because of a wrong pathname. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Drive Paths D. File names 3 G. File names 6 │ │B. File names 1 E. File names 4 H. File names 7 │ │C. File names 2 F. File names 5 │ │ │ │Which would you like to do ([Enter] to quit): │ └──────────────────────────────────────────────────────────────────────────┘ Which in turn break down to the following screens: However, BE THEE WARNED: the pathnames displayed on your screen will always be the "post-processed" pathnames. AFTER they had their "???"'s and RAM Drive equivalent paths changed. But when you change it, feel free to use "???"'s if you want--they too will show up as post-processed equivalents. In other words, where I have "c:\bbs\node.???\" you will see "c:\bbs\node.001\" even though it is really stored as "c:\bbs\node.???\". ┌──────────────────────────────────────────────────────────────────────────┐ │A. BBS/main/uploads drive: C:\ │ │B. Primary BBS path: C:\BBS\ │ │C. Path of files to go to RAM drive: C:\BBS\NODE.???\RAMDRIVE\ │ │D. RAM drive: E:\ │ │E. Path for file attaches: C:\BBS\GLOBAL\MSGSTUFF\ │ │F. Path containing the text files: C:\BBS\GLOBAL\TEXT\ │ │I. Path for extracting files: C:\BBS\NODE.???\TEMPAREA\ │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ These are the paths the BBS shall use. "d:\" is determined when you run the program for the first time. When you change one of these entries, the directory will be created if it does not already exist. BBS/main/uploads drive This is your primary drive. It should be the drive in which most of your BBS files--certainly those files that are changeable--and your primary upload drive. Primary BBS path This is the path out of which you run JDR_BBS, it should contain the batch files. Path of files to go to RAM drive This is the path to your primary ANSI files (or anything else) that you want to put in a RAM disk at startup. If your RAM drive is "E:\" you will usually see an "E:\" here also. RAM drive This defines where that RAM drive is, if the same as "Path of files to go to RAM drive:" then its assumed you are not using a RAM drive--in which case the files will not be copied over. Change this to your RAM drive (eg. "E:\"). It will take effect the next time you start the BBS. There is no need to go through and change every pathname you wish to be on the RAM drive; change this to what you want, then exit and restart the BBS. Path for file attaches This is the directory where file attaches will be put. File attaches are stored in this directory under their own directory corresponding to the formula: MessageNumber.MessageArea Example: message 5000 in Private Mail (area 001) has its files stored in \MSGSTUFF\5000.001. Path containing the text files This is the path to the BBS's files that can be edited with a text editor. Except for MESSAGE.xxx files, these are files you or your users create. Path for extracting files When we wish to extract a file, to again compress into EXTRACT.ZIP, this is where the extracted files are temporarily stored. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Users data pathname: C:\BBS\GLOBAL\SYSTEM\USERS │ │B. Message headers data pathname: C:\BBS\GLOBAL\SYSTEM\MESSAGES.HDR │ │C. User message data pathname: C:\BBS\GLOBAL\SYSTEM\USERMSGS │ │D. Files information pathname: C:\BBS\GLOBAL\SYSTEM\FILELIST │ │E. Peer Review voting data pathname: C:\BBS\GLOBAL\SYSTEM\PEERREVW │ │F. "Lines" of text pathname: C:\BBS\NODE.???\LINES.TXT │ │G. "Blocks" of text pathname: C:\BBS\NODE.???\BLOCKS.TXT │ │H. Filenames pathname: C:\BBS\GLOBAL\SYSTEM\FNAMES │ │I. Spell words file names: C:\BBS\GLOBAL\GRAMMAR\WORDS │ │J. Temporary work pathname: C:\BBS\NODE.???\TEMPAREA\TEMPFILE │ │K. Emergency space pathname: C:\BBS\GLOBAL\SYSTEM\8192.BUF │ │L. LINES image pathnames: C:\BBS\NODE.???\RAMDRIVE\LINES.$$$ │ │M. Results/stats info pathname: C:\BBS\GLOBAL\SYSTEM\RESULTS │ │N. Requests pathname: C:\BBS\GLOBAL\TEXT\REQUESTS.TXT │ │O. Reviews file names: C:\BBS\GLOBAL\TEXT\REVIEWS. │ │P. BBS Reviews pathname: C:\BBS\GLOBAL\TEXT\BBSREV.TXT │ │Q. Skills/fields pathname: C:\BBS\GLOBAL\TEXT\SKILLS.TXT │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Users data pathname This file contains the users records. Message headers data pathname This file contains the message header records and message text. User message data pathname This file contains the information about message bases and users. High message read, toggle status, access status, and messages waiting. Files information pathname This file contains the file records for all downloadable files. Peer Review voting data pathname This file contains information on which users already voted for which peer review. "Lines" of text pathname This file contains most of the text the BBS uses for everything. You may edit what you do not like. "Blocks" of text pathname This file contains text that is larger than a single line, DataBaser definition blocks, menu blocks. Filenames pathname This file contains the first 8 letters of all files that have been uploaded to the BBS. It will be part of check on-line lists and duplicate upload checking routines for the future. Spell words file names These files contain the words for the Grammar Check message spell checker. Temporary work pathname This is a temporary work file, used for a variety of things. Do not give it an extension--to create multiple temporary files the software attaches an extension to this name. Emergency space pathname This is the name of the BBS's emergency space file, for when an uploader uses up all the drive space. LINES image pathname This is a system created file. It is a slightly smaller version of LINES.TXT. It is this file that the software will copy to a RAM disk. Results/stats info pathname This file stores the system configuration information, the voting results, and the information for the stats screens. Requests pathname This file contains file requests by you and your users. Reviews file names This file contains file reviews by you and your users. BBS Reviews pathname This file contains reviews of other BBS's. Skills/fields pathname This file contains the jobs/professions of you and your users. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Linkages information pathname: C:\BBS\GLOBAL\SYSTEM\LINKAGES.DAT │ │B. Files-to-search database pathname: C:\BBS\GLOBAL\SYSTEM\SEARCH.DAT │ │C. File areas definitions pathname: C:\BBS\GLOBAL\SYSTEM\FILEAREA.DAT │ │D. Voting questions pathname: C:\BBS\GLOBAL\TEXT\VOTE.TXT │ │E. Quotes pathname: C:\BBS\GLOBAL\TEXT\GOODBYE.TXT │ │F. News pathnames: C:\BBS\GLOBAL\TEXT\NEWS. │ │G. 'Already have' list pathname: C:\BBS\ALSO_GOT.LST │ │H. Callers log pathname: C:\BBS\NODE.???\CALLERS.LOG │ │I. Caller stats pathname: C:\BBS\GLOBAL\SYSTEM\SUMMARY.DAT │ │J. DSZ's log pathname: C:\BBS\DSZLOG │ │K. DSZ executable pathname: C:\BBS\DSZ.EXE │ │L. Errors log pathname: C:\BBS\ERRORS.LOG │ │M. PKZIP executable pathname: C:\BBS\PKZIP.EXE │ │N. PKUNZIP executable pathname: C:\BBS\PKUNZIP.EXE │ │O. LHA executable pathname: C:\BBS\LHA.EXE │ │P. ARJ executable pathname: C:\BBS\ARJ.EXE │ │Q. Paths information pathname: C:\BBS\PATHS.DAT │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Linkages information pathname This file contains information on whose linked to who for "download support". If you change this name, you should also change the name in BLOCKS.TXT block 08. Files-to-search database pathname This file contains the file names of files to search when a user does an off-line search--such as before uploading. File areas definitions database This file contains information about your file areas. See also: FILE AREAS Voting questions pathname This file contains your voting questions and options. Quotes pathname This file contains quotes. News pathnames This file contains news items for when log on. 'Already have' list pathname This file contains the file name, size, and description, of files you already had up on the BBS--and do not want users to put up again. Callers log pathname This is the logging file, it holds a variety of information. Delete it when it gets too big. Caller stats pathname This file contains information on each caller for statistical stuff. DSZ's log pathname Path to DSZ's log file. Used with net mail transfers. DSZ executable pathname Path to DSZ program. Used with net mail transfers. Errors log pathname This file contains various error and file adjustment reports. PKZIP executable pathname Path to PKZIP program. PKUNZIP executable pathname Path to PKUNZIP program. LHA executable pathname Path to LHA program. ARJ executable pathname Path to ARJ program. Paths information pathname This file contains the path information that is displayed on these screens. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Message area index pathnames: C:\BBS\GLOBAL\INDEXES\MSGS_ │ │B. Database of sysops pathname: C:\BBS\GLOBAL\SYSTEM\SYSOPS.DAT │ │C. Database of doors pathname: C:\BBS\GLOBAL\SYSTEM\DOORS.DAT │ │D. Message area info pathname: C:\BBS\GLOBAL\SYSTEM\MSGBASES.DAT │ │E. Message file names: C:\BBS\GLOBAL\MSGSTUFF\MESSAGE. │ │F. Backup batch pathname: C:\BBS\BACKUP.BAT │ │G. Deleted messages pathname: C:\BBS\DEL_MSGS.TXT │ │H. Higher access pathnames: C:\BBS\NODE.???\ANSI\ACCESS │ │I. Ramblings information pathname: C:\BBS\GLOBAL\SYSTEM\RAMBLING.DAT │ │J. Directry data pathnames: C:\BBS\GLOBAL\TEXT\DIRECTRY.D │ │K. Directry title pathnames: C:\BBS\GLOBAL\TEXT\DIRECTRY.T │ │L. Directry index pathnames: C:\BBS\GLOBAL\INDEXES\DIRECTRY.I │ │M. Survey/questionnaire pathnames: C:\BBS\GLOBAL\TEXT\SURVEY. │ │N. Survey answer pathnames: C:\BBS\GLOBAL\TEXT\ANSWERS. │ │O. UL/DL files list pathname: C:\BBS\NODE.???\FNAMES.CTL │ │Q. Trap All pathname: C:\BBS\SESSION.LOG │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Message area index pathnames These files contain the index data for each message area. Database of sysops pathname This file contains information on other BBS's that you call. If you change this name, you will also need to change block 09 in BLOCKS.TXT. Database of doors pathname This file contains information about your door programs you wish to run. If you change this name, you will also need to change block 38 in BLOCKS.TXT. Message area info pathname This file contains information about your message areas. If you change this name, you will also need to change block 10 in BLOCKS.TXT. Message file names These files are created when you use the "%" command. They are message files, accessible in other messages via the "%%%xxx" command. Backup batch pathname This is only used to create your backup batch file when you first set up the BBS. Deleted messages pathname When packing, this file gets your deleted messages. It also gets a copy of the deleted rambles. Higher access pathnames This is a pathnames fragment. A "*.*" is attached to its end, and all file names matching the resulting wildcard will be considered. These files are for the "Ninf" command--higher access ANSI screens. Ramblings information pathname This file contains the information about what rambles are available. Directry data pathnames These files contain the text for the "directry" system's entries you create. Directry title pathnames These files contain the titles for the "directry" system's entries you create. Directry index pathnames These files contain an index off all the entries in a "directry" systems you create. Survey/questionnaire pathnames These files contain the questionnaires. Survey answer pathnames These files contain the answers to the questionnaires. UL/DL files list pathname This file contains the pathnames of any files just downloaded (if a download only session) or those just uploaded (if a upload only or bidirectional session). The file exists until the next file transfer. For "download only" protocols this file will contain files selected (they may or may not have been sent successfully), for uploads and bidirectional protocols, it will contain files received successfully, but not any of the files that were sent. Trap All pathname When you have trapping of everything to a log file, this is the file where it is all stored. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Trap Chat pathname: C:\BBS\CHAT.LOG │ │B. Rambling text pathnames: C:\BBS\GLOBAL\TEXT\RAMBLING. │ │C. Door batch pathname: C:\BBS\DOOR???.BAT │ │D. BBS batch pathname: C:\BBS\BBS???.BAT │ │E. Users index pathname: C:\BBS\GLOBAL\INDEXES\USERS.IDX │ │G. ANSI file to display to new users: C:\BBS\NODE.???\ANSI\NEWUSER.ANS │ │H. Files index pathname: C:\BBS\GLOBAL\INDEXES\FILES.IDX │ │I. Short strings pathname: C:\BBS\GLOBAL\TEXT\SHORT.TXT │ │J. LINES index pathnames: C:\BBS\NODE.???\LINES.IDX │ │K. BLOCKS index pathnames: C:\BBS\NODE.???\BLOCKS.IDX │ │O. Any user's first profile screen: C:\BBS\NODE.???\ANSI\PROFILE3.ANS │ │P. Any user's second profile screen: C:\BBS\NODE.???\ANSI\PROFILE4.ANS │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Trap Chat pathname When you have trapping of chat sessions on, this is the file where it is all stored. Rambling text pathnames These files store the text for the rambling topics. Door batch pathname This file is run when executing a door. BBS batch pathname This file is run when executing the BBS. Users index pathname This file contains index data for the user records. ANSI file to display to new users This ANSI is shown to new users when they first logon. Files index pathname This file contains index data for the download files records. Short strings pathname This file contains really short strings of text that are to be loaded to memory. LINES index pathname This file contains index data for the LINES.$$$ image file. BLOCKS index pathname This file contains index data for the BLOCKS.TXT file. Any user's first profile screen This is the template ANSI that is first displayed with the "ProA" menu command. Any user's second profile screen This is the template ANSI that is secondly displayed with the "ProB" menu command. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Protocol database pathname: C:\BBS\GLOBAL\SYSTEM\PROTOCOL.DAT │ │B. Routing database pathname: C:\BBS\GLOBAL\SYSTEM\ROUTING.DAT │ │C. Security level database pathname: C:\BBS\GLOBAL\SYSTEM\SL.DAT │ │D. Events database pathname: C:\BBS\GLOBAL\SYSTEM\EVENTS.DAT │ │E. Messages bodies pathname: C:\BBS\GLOBAL\SYSTEM\MESSAGES.BDY │ │F. Modem CONNECT strings pathname: C:\BBS\GLOBAL\SYSTEM\CONNECT.DAT │ │G. Node-dependent settings pathnames: C:\BBS\GLOBAL\SYSTEM\SETTINGS.??? │ │I. Message compression and menu info: C:\BBS\GLOBAL\SYSTEM\INTERNAL.TXT │ │J. Names to not allow to login: C:\BBS\GLOBAL\TEXT\NOTNAMES.TXT │ │K. Comment file for ZIP/ARJ's: C:\BBS\GLOBAL\TEXT\COMMENT.TXT │ │L. Message downloading storage file: C:\BBS\NODE.???\TEMPAREA\MESSAGES.TXT│(oop's) │M. Menu commands structure pathname: C:\BBS\NODE.???\MENUS.DAT │ │N. Command categories pathname: C:\BBS\GLOBAL\SYSTEM\CATEGORY.DAT │ │O. Command definitions pathname: C:\BBS\GLOBAL\SYSTEM\CMDS.DAT │ │P.Menu commands definitions pathname: C:\BBS\NODE.???\BBS_CMDS.DAT │ │Q. Special effects pathname: C:\BBS\NODE.???\FX.TXT │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Protocol database pathname This file contains the protocols your users are able to use. If you change this name, you should also change the name in BLOCKS.TXT block 47. Routing database pathname This file contains routing ("where to send") information for your EchoMail message areas. Security level database pathname This file contains your security level information. If you change this name, you should also change the name in block 42 in BLOCKS.TXT. Events database pathname This file contains your events information. If you change this name, you should also change block 39 in BLOCKS.TXT. Messages bodies pathname This file contains the actual message text. Modem CONNECT strings pathname The modem CONNECT strings your modem sends out. If you change this name, you should also change block 55 in BLOCKS.TXT. Node-dependent settings pathnames This file stores the settings information for each node you create. Message compression and menu info This file contains the message compression information. Names to not allow to login This file should contain names/words you do not wish to allow to logon on. Each line should contain one "checker" word/name. That is, when the user is entering their name during login, they will have their first name, last name, and full name compared against each line of this file. If there is a match, they are asked to enter another name. The file is only checked when a caller hits [Enter]. This means if you have "SYSOP SYSOP" on a line, and the user enters "SYSOP<ret>" it will not be caught, but if the caller enters "SYSOP SYSOP<ret>" or "SYSOP<ret>SYSOP<ret>" it will be caught. This allows "SYSOP<ret> OF ARABIA<ret>" to be a name, for example. Too eliminate both, use two lines: one with "SYSOP" and one with "SYSOP SYSOP". If you have "handles allowed" toggled to on, then it really becomes an exact comparison, since the software does not ask users for last names when "handles" are allowed. Comment file for ZIP/ARJ's If this file exists, then it is automatically added into uploaded ZIP or ARJ files as the archive comment (replacing whatever one is there). The file should contain no ANSI codes. ARJ only uses the first 2048 bytes of the file. There must be the defined minimum space for ZIP's, and the file's size + minimum space for ARJ's, before the software will do it. A file of size zero will simply clear out archive comments. If the pathname contains a wildcard, then the software will use a randomly selected one of those files that match. Message downloading storage file This file is used to store messages for message downloading with the ASCII and ANSI methods. Menu commands structure pathname This file stores which menu commands are stored in which menu. Command categories pathname This file stores which menu commands are stored in which category. Command definitions pathname This file stores the functionality of each menu command. Menu commands definitions pathname This file stores the parameters for each menu's menu commands. Special effects pathname This file contains the special-effects strings to be displayed when menu commands are selected. This file is a standard text file and can be edited whenever you want. ┌──────────────────────────────────────────────────────────────────────────┐ │A. Master List work pathnames: C:\BBS\MASTER.LS │ │B. Master List archive 1 pathname: C:\BBS\MASTER.ZI1 │ │C. Master List archive 2 pathname: C:\BBS\MASTER.ZI2 │ │D. Master List archive 3 pathname: C:\BBS\MASTER.ZI3 │ │E. Master List archive 4 pathname: C:\BBS\MASTER.ZI4 │ │F. Master List archive 5 pathname: C:\BBS\MASTER.ZI5 │ │G. Master List archive 6 pathname: C:\BBS\MASTER.ZI6 │ │H. Master List archive 7 pathname: C:\BBS\MASTER.ZI7 │ │I. Master List archive 8 pathname: C:\BBS\MASTER.ZI8 │ │J. Master List archive 9 pathname: C:\BBS\MASTER.ZI9 │ │K. Master List before ZIP pathname: C:\BBS\MASTER.LST │ │L. Master List download pathname: C:\BBS\MASTER.ZIP │ │M. File comparing index 1 pathname: C:\BBS\FILE1.IDX │ │N. File comparing index 1 pathname: C:\BBS\FILE2.IDX │ │O. File comparing results pathnames: C:\BBS\COMPFILE. │ │Q. Pathname of BBS's logo ANSI: C:\BBS\NODE.001\ANSI\LOGO.ANS │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ Master List work pathnames Temporary files for the up-to-9 Master List's. Master List archive 1 pathname Master List archive 2 pathname Master List archive 3 pathname Master List archive 4 pathname Master List archive 5 pathname Master List archive 6 pathname Master List archive 7 pathname Master List archive 8 pathname Master List archive 9 pathname These are the Master List files. Each ZIP represents a different file areas SL tier. Master List before ZIP pathname This is the name of the Master List file in each MASTER.ZIx archive. Master List download pathname This is the name to change the MASTER.ZIx files to before sending it to the caller. File comparing index 1 pathname This is a temporary file used in the comparison of two file lists. File comparing index 1 pathname This is a temporary file used in the comparison of two file lists. File comparing results pathnames This file contains the results of comparing two file lists. Pathname of BBS's logo ANSI Pathname of your LOGO screen. This is (only) used for .QWK packets, to supply them with a "HELLO" ANSI. If you want your .QWK packets to contain a different ANSI, just use that name here instead. ┌──────────────────────────────────────────────────────────────────────────┐ │A. ANSI to display for Msg DL'ing: C:\BBS\NODE.???\ANSI\MSGDL.ANS │ │B.Pathname to store archive comments: C:\BBS\GLOBAL\TEXT\COMMENTS.OUT │ │C. EchoMail AREA: name re-mapper: C:\BBS\GLOBAL\SYSTEM\ECHOS.DAT │ │D. Node lists database pathname: C:\BBS\GLOBAL\SYSTEM\NODELIST.DAT │ │E. Node lists index pathname: C:\BBS\GLOBAL\INDEXES\NODELIST.IDX │ │ │ │Type letter to modify or [Enter] to continue: │ └──────────────────────────────────────────────────────────────────────────┘ ANSI to display for Msg DL'ing This is the ANSI you wish to display for the "Message Downloader" menu. Pathname to store archive comments This is the file to which you wish to put extracted .ZIP header comments. EchoMail AREA: name re-mapper This is the data file for re-mapping incoming EchoMail conference names to your own areas. Node lists database pathname This is the data file containing the pathnames of the node lists you wish to the software to use. Node lists index pathname This is an index file created that contains the node addresses and their location from each of the node list files you wish to be part of your BBS. Except for "Ram Drive", all path and file name entries also are in use immediately after the change. If this causes problems, then you should bridge the old and new name by first copying the old file to the new name, change the settings name, then delete the old file. CONVERSION Some advice on converting from another BBS program: Use the Import Descriptions command to convert file descriptions. ANSI's should not be any problems, although you will have to match your menu commands with my functions. It is best to phase this in one or two commands at a time. If you are currently using RemoteAccess, Telegard, Renegade, or SpitFire, then you can convert your users and messages files with CONVERT.EXE. If you are using something else, then use this program as an example, and modify it to suit your current BBS's data structures. The program is entirely self-contained in standard DOS Basic. If you need help, just ask me, chances are I will do it for you. If you make changes, send me them so that others may benefit. The convert program has not undergone a lot of testing--if it does not work, tell me and I will give you a fixed version. Telegard and RemoteAccess seem to have a lot BBS programs that use the same format (are rip-off's of these rip-off's), they may be convertible as well. For some others, it might be useful to use an intermediary conversion step (for example, WWIV to RA to JDR_BBS). MODEM SETUP You should make sure to switch your modem's auto-answer feature off. Whether it requires a hardware switch, or a software switch, depends on your make. You must have a fossil driver installed. There are two that I know of: X00 and BNU. "Fossil" is the common terminology for this type of program, it actually is a "Communications API". API (Application Programming Interface) is a word we will be hearing a lot of in the 90's. DSZ could be considered a protocol API. They all serve to make programming a lot easier. There are three "musts" you modem must be able to do: It must return "CONNECT xxxxxx" lines. Where "xxxx" is the caller's baud rate. It must have a "CR/LF" after each line it sends. It must be able to hang up when DTR is lowered. Normally, most modems do the above (certainly any new ones). Your modem should be configured as such: Modem echos data (usually E1). Modem sound off (usually M0). Result codes displayed (usually Q0). Full result codes (usually X4). Verbal result codes (usually V1). Auto-answer off (usually S0=0). DTR follows connection (usually &D1). Carrier-Detect (CD/DCD) follows connection (usually &C1). So, usually ATE1M0Q0X4V1S0=0 will do it. However, some modems need an &C1, &D1, or other commands. If you find that your modem is staying off hook (such as after you logon locally) add an H0 (hang up phone) command to your initialization string. If you are confused, then do not change what I have. ATZ for the initialization string usually works with any modem. For some commands, the computer goes into an infinite loop (locks up) when you specify a port for which you do not have a modem. Also, it may lock up if you have configured the fossil wrong (particularly if you specified a baud rate your modem cannot handle, since all your modem see's is gibberish when the fossil try's to talk to it). The CONNECT strings database is divided into three fields: The CONNECT strings modems send, the maximum CPS rate that that connection yields, and what to show for that connection when a user downloads files. When a call comes into the software, the database is scanned for a string that matches what the modem sends. If none is found, then the phone is hung up, and a "non-user" log note is made. The following is a checklist for setting up your modem: 1. Do the X00 command set up. 2. Put your correct initialization commands in LINES.TXT. 3. Make sure the CONNECT strings database has every connect string your modem can send (that is, those you want to allow). 4. Change the communications port to that of your modem in Settings. <alt>s (shelling to DOS) and local logon takes the phone off the hook. <alt>x (exit to dos) does not take the phone off the hook. For dialing, I assume ATDT, but you can change this in SHORT.TXT. Search for "dt" and "dt1-". LINES.TXT lines 625 to 628 contains the commands sent to the modem to do various things. The modem will show you what it is sending and receiving while trying to initialize the modem (and when dialing or receiving a call). If it fails to initialize, then it is usually due to you setting up the fossil or your modem initialization string wrong. Be sure you set your baud rate in Change Settings to the maximum your modem can handle. See also: LINES.TXT, APPENDIX J, SETTINGS, CONFIG Problems If you find that when calling your BBS the keys you type at menu's are not immediately responded too--some more text is sent before it responds--then you should make sure your modem is configured for it's smallest possible internal buffering. That is, rather than let the modem's hardware do buffering, we want to let the fossil handle buffering. For modem/connection problems when just getting started, there are two steps: The first involves <alt>d from the waiting-for-caller screen. If you are able to enter a "H0", and the modem responds with "OK" when it sends ATH0. When you get an "OK", you know that the fossil driver and modem initialization setup is, for the most part, correct. If you do not get an "OK", to "H0" or any other valid command, then either the fossil is set up wrong, or the modem initialization string is wrong. The next solution, usually for figuring out more complex problems, is the <alt>p command from the waiting-for-caller screen. Whereas <alt>d is a one-shot-at-a-time modem sender, this command puts you in continuous command mode. So everything you type goes directly to the modem, and everything the modem receives you see directly. Exactly like the command mode of any communications/terminal program. <alt>p relies on your Settings baud rate. Remember the 3 modem status buttons at the waiting-for-caller screen: CTS, DSR, DCD. CTS probably does not matter. But DSR and DCD should be in the "up" position when no caller is trying to call. And should go "down" before you start seeing the information that the modem is receiving (CONNECT string). If this is not occurring, you should make sure your modem initialization string, and maybe your hang up string, produce these results. TERMINAL See the <alt>d command information in CONSOLE KEYS. PROGRAM <alt>d enters the terminal program. You are given a simple "do what" question. You may either choose to send a command to the modem directly, use the "d" and "c" commands. "dt xxx-yyy-zzzz" would be to call another computer. "d" alone will access your Sysops database. "d xxxx" will dial the number of the Sysops database entry that contains the string "xxxx" in any of its fields. If more than one entry contains the string, you will be asked to select which entry to call. "c xxxx" works like "d xxxx" but instead of one attempt it will make continuous attempts. Type "?" for the available commands. When you have contacted another BBS, the following keys are active: <f1> toggles the trapping of all comm I/O to a file. <f2> Send a file (ASCII send--no protocols). Can use wildcards to send a random file from a bunch of files. No stop/exit key handling is done. <pgup> to send a file. You must enter the full path and filename of the file(s) to upload--wildcards are OK. <pgdn> to receive a file. After starting the transfer just hit <pgdn>. <end> to transmit any net mail meant for that BBS. If you did not dial with "d string" or "c string" then it will ask you which net address to use-- otherwise it uses the net address for that sysops database entry. Once hit, there is no way to abort <end>--since the other BBS will now accept nothing less than a mail attempt. <alt>h to hang up. │ <alt>l to "turn the tables". This allows the sysop on │ the other end to log into your BBS as if it were │ they who called you. If using JDR_BBS, then that │ sysop must be in <alt>p mode. If using another │ BBS program, then they must be in a "pure mode"-- │ that is, where they accept everything that comes │ in, and do not send ANSI codes back out (example, │ chat is not a "pure mode", when it changes colors │ depending on who is "talking".). <alt>s to shell to DOS. From the shell, you may execute a different protocol, or use something like LIST to examine the trapping file (if you were trapping). <c><left> <control><left> This will send an ASCII 27. It is expected that you will follow up this key with a valid ANSI string--none of which will be displayed. │ The arrow keys will send out the appropriate ANSI codes for │ arrow key movements. I am not sure if this is unique to having an HST: but when I call 2400 baud BBS's, their initially sent information is not shown, and I have to hit [Enter] (which tells the called BBS to re-ask its last question or to move onto the next ANSI). This is not a problem at MNP connects. On some BBS's, you will be able to use <Control>S to pause, and <Control>Q to un-pause (note, you may have to hit <Control>Q twice. Unfortunately, one of the most useful abilities of most communications programs is missing: the backscroll buffer. I do plan to add this. If the BBS you call has Avatar display codes, you can toggle it to ON on that BBS. No toggle is needed on this end as the software looks for ANSI and Avatar codes all the time. High-speed modems usually have large buffers. A slow computer can lead to situation in which the buffer can be filled faster than the characters are written to the screen (especially so if you have trap ON). To get around this, the software clears this input buffer every time you type a character. It should not cause any troubles--it should not even be noticed--but if it does, let me know. The faster your computer and modem, the larger your receive buffer ("R=" in fossil initialization string) should be. When calling another number, if all you get is RINGING's, then after you hit a key to abort the process, enter an "H0" for the command string to hang up the phone. SPECIAL THANKS To the users of Immortality--who have been putting up with oft-times flaky software and a non-attentive sysop for two years now as I have developed this software. NEXT DOCS_2 should be your next stop.